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(57) ABSTRACT 

A wireless communications device with a markup language 
based man-machine interface provides a user interface for 
telecommunications functionality, including dialing tele- 
phone numbers, answering telephone calls, creating mes- 
sages, sending messages, receiving messages, establishing 
configuration settings defined in markup language such as 
HTML, and accessed through a browser program executed 
by the wireless communication device. This feature enables 
direct access to Internet and World Wide Web content, such 
as Web pages, to be directly integrated with telecommum- 
cation functions of the device, and allows Web content to be 
seamlessly integrated with other data types, since all data 
presented to the user via the user interface is presented via 
markup language -based pages. The browser processes an 
extended form of HTML that provides new tags and 
attributes that enhance the navigational, logical, and display 
capabilities of conventional HTML, and particularly adapt 
HTML to be displayed and used on wireless communication 
devices with small screen displays. 
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<HTML> 

%£?m* LABEL" " PhoneBook " ACTION.-f Ue^/phonbooK.htnd" > 
*KSW KEY=1 LABBL-'Menu" ACTIOK-MENU> 

<KKYMKNU KEY-1 LABEL- "Phone Settings 

ACTION*" file://phoneett. html" > 

<KEY KEY-up action-"file: //recent. html"> 
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HTMLp 

<HTML> 
cHEAD> 
<TOP> 

<TITLE> Phone Book</TITLE> 
<KBY KEY-1 Label«=New Action* "new" > 
<KEY KEY»clear action»delete> 
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</HEAD> 

<BODY> 

<OBJECT 
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</BODY> 

</HTML> 



FIG. 8 
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Result 



file info.html 

<HTML> 

<INC SRC-bbody.html> 

<centerxfont si2e«l> Information 

S e rvi ces < / f ont > <br >< / cent e r > 

<FORM ACTION*phone:indir> 

< SELECT SIZE=3 NAMB=url SIMPLE> 

^OPTION 

VALUB=http://svcs/traf f ic.html >Traff ic 

Watch</OPTION> 

<OPTION 

VALUE=http : //svcs/billing . html>Billing 

Inquiriea</OPTION> 

<OPTION 

VALUE=http : //svcs/portf olio , html>Stock 
Portfolio< /OPTION* 

<OPTION VALUE=http : //svcs /weather . html>Local 

Weather </OPTION> 

</SBLBCT> 

< INPUT TYPE=submit KEY=send> 
</PORM> 

<INC SRC«endbbody.html> 
</HTML> 



1231 



I A V p t e'i 

Information Services 
> Traffic Watch 

Billing Inquiries 
S tockPortfolio 



file bbody.html t 

<i Specifies a body surrounded by a 
border with the operator logo at the 
top. The including file can add a 
subcaption immediately below, but left 
and right margin are set so text will 
not impinge on the border > 
<B0DY BACKGROUND=sq-back.gif 
BGPROPERTI ES- f ixed> 
<BLOCKQUOTE> 
<BR> 

<INC SRC= atdlogo.htTnl> 



FIG. 13 



file endbbody.html; 

<! Closes the tags that were opened by 

bbody.html> 

</BL0CKQU0TB> 

</BODY> , _^____^__„ 



file stdlogo.htmlt 

<I Provides the operator logo with the text 
flow set to receive a subcaption for the 
logo > 

<IMG SRC=l-airtel.gif> 
<BR> 
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Client Server 



<HTML> | 
<HEAD> | 
<TITLE>Pur chase Skis</TITLE> j 
</HEAD> 1 
<BODY> I 
Finally, your credit card info: 1 
<FORM METHOD-GET | 
ACTI ON= » ht t p : / / ski shop/ eg i - b in/ c onf inn" > | 
<INPUT TYPE«hidden NAME =n a me j 
VALUE=" George Will"> | 
< INPUT TYPE-hidden NAME=street VALUE-" 2 | 

Anywhere" > 

<INPUT TYPE=hidden NAME=city 
VALUE=" Madi son" > 

< INPUT TYPE=hidden NAME=state VALUE="WI"> 
<INPUT TYPE=hidden NAME=zip 
VALUE-" 53705" > 

Credit Card:<br> | 
< INPUT TYPE=RADIO NAME=cardtype | 
VALUE= vi s a >VI SA | 
< INPUT TYPE=RADIO NAME=cardtype | 
VALUE=mc>MasterCard 1 
< INPUT TYPE=RADIO NAME=cardtype 
VALUE=amex>American Express<br> 
Number: < INPUT TYPE=TEXT NAME =c number > 
<INPUT KEY = send TYPE -submit name=buy 
valuer" Review* > 
</FORM> 
</BODY> 

</HTML> . . 




GET http://skishop/cgi- 

bin/credit?name=George+Will&street*2+Anyw 
here&city=Madison&s t ate=WI &zip«53 7 05 fccard 
type*visa&cnumber-77322221566610.00 






Insert credit card 
parameters into template 
maintained on the server, 
and upload to client. 



FIG. 17b.1 
PRIOR ART 
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Client 


Server 


<HTMLi> 1 




<HEAD> 1 


<TITLE>Conf irm Order</TITLE> | 


</HEAD> j 


<BODY> 




<DL> 




<DT>Name : </DTxDDxb>George Will</bx/DD> 




<DT>Address : < /DTxDDxb>2 Anywhere , 




Madison, WI, 53705</bx/DD> 




<DT>Credit Card:</DTxDDxb>VISA<br> 




7732222156661000</bx/DD> 




</DL> 




<PORM METHOD^ POS T J 


ACTION="http : / / ski shop /cgi -bin/purchase" > j 


< INPUT TYPB~hidden NAME=name 1 


VALUE-" George Will ff > I 


< INPUT TYPE-hidden NAME=street VALUE-" 2 J 


Anywhere" > 1 


< INPUT TYPE^hidden NAME- city | 


VALUE = * Madi son* > J 


<INPUT TYPE=hidden NAME= state VALUE="WI"> 1 


< INPUT TYPE = hidden NAME=zip 




VALUE-'' 53705'' > ~ 




<INPUT TYPE=hidden NAME«cardtype 




VALUE="visa"> 




< INPUT TYPE=hidden NAME=cnumber 




VALUE=" 7732222156661000" > 




< INPUT KEY=1 TYPE=submit name-buy 




value- "Buy ! " > 




</FORM> 




</BODY> 




</HTML> 




POST http://skishop/cgi- 




bin/purchase?naTne=George+Will&street=2+An 




ywhere&city=Madison&state«WI&zip=53705&ca 




rdtype=visa&cnumber=7732222156661000 






Process transaction with 




all parameters. 



FIG. 17b.2 
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WIRELESS COMMUNICATION DEVICE WITH 
MARKUP LANGUAGE BASED MAN-MACHINE 
INTERFACE 

RELATED APPLICATIONS 

[0001] This application is a continuation of application 
Sen No. 09/604,833, filed Jun. 27, 2000, which is a con- 
tinuation of application Ser. No. 09/057,394, filed Apr. 8, 
1998, now U.S. Pat. No. 6,173,316, which is incorporated 
herein by reference in its entirety. 

BACKGROUND 
[0002] 1 . Field of Invention 

[0003] This invention relates to man-machine interfaces 
for wireless communication devices, and more particularly, 
to man-machine interfaces constructed from markup lan- 
guages. 

[0004] 2. Background of the Invention 

[0005] Wireless communication devices are becoming an 
increasingly prevalent for personal communication needs. 
These devices include, for example, cellular telephones, 
alphanumeric pagers, "palmtop" computers and personal 
information managers (PIMS), and other small, primarily 
handheld communication and computing devices. Wireless 
communication devices have matured considerably in their 
features, and now support not only basic point-to-point 
communication functions like telephone calling, but more 
advanced communications functions, such as electronic 
mail, facsimile receipt and transmission, Internet access and 
browsing of the World Wide Web, and the like. 

[0006] Generally, wireless communication devices have 
software that manage various handset functions and the 
telecommunications connection to the base station. The 
software that manages all the telephony functions is typi- 
cally referred to as the telephone stack, and the software that 
manages the screen display and processes user inputs of key 
presses is referred to as the Man-Machine-Interface or 
"MMI." The MMI is the topmost, and most visible layer of 
the wireless communication device's software. 

[0007] Because wireless communication devices have 
generally reached a very desirable and small form factor, the 
primary determinant of a successful device will likely be in 
its feature set and its ease of use. Thus, the ability to quickly 
design, test, and deliver wireless communication devices 
that are both easy to use, and have a rich set of features — 
attributes that are often opposed to one another — will be 
essential to successful product performance. 

[0008] However, wireless communication devices present 
a variety of more challenging design and implementation 
issues that do not arise with larger processor-based systems, 
such as notebook and desktop computers, which may also 
have similar telecommunication features. These design chal- 
lenges include the design of the user interface, the customi- 
zation of the devices for particular service operators, the 
integration of Internet and World Wide Web access with 
other communication functionality, and the software devel- 
opment process. 

[0009] User Interface Design Constraints 

[0010] Unlike desktop and notebook computers, wireless 
communication devices have a form factor which requires a 



very small screen display size. Desktop computers typically 
have displays with at least 14" screen size, and resolution 
typically between 640x480 and 1024x768 pixels. In con- 
trast, wireless communication devices typically have a 
screen size between 25x25 mm and 80x20 mm, and reso- 
lutions between 90x60 to 120x120 pixels, or about 3-8% of 
the size of the desktop or notebook screen. As a direct result, 
the user interface design of the wireless communication 
device must provide access to essentially the same features 
as desktop computers, such as electronic mail, facsimiles, 
and Web browsing, yet with only a fraction of the screen area 
for displaying text, images, icons, and the like. This problem 
of constructing the user interface to provide these features is 
particularly significant when handling Web based content, 
since conventional Web content, such as forms, assume the 
larger screen size of conventional desktop computers. Dis- 
playing such forms on the small screen of a wireless 
communication device results in jumbled and difficult to use 
content. 

[0011] Another user interface limitation of wireless com- 
munication devices is the severely restricted set of inputs 
available to the user. Conventional desktop or notebook 
computers have cursor based pointing devices, such as 
computer mouse, trackballs, joysticks, and the like, and full 
keyboard. This enables navigation of Web content by click- 
ing and dragging of scroll bars, clicking of hypertext links, 
and keyboard tabbing between fields of forms, such as 
HTML forms. Wireless communication devices have a very 
limited number of inputs, typically up and down keys, and 
one to three softkeys. 

[0012] Accordingly, it is desirable to provide a software 
architecture for the MMI of a wireless communication 
device that enables the customization and use of user 
interface with Web content accounting for the limited screen 
resolution and input functionality of the wireless commu- 
nication device. 

[0013] Integration of Internet/Web Functional with Tele- 
phony 

[0014] With the advent of the Internet and the World Wide 
Web, the highest performance wireless communication 
devices provide complete Internet access and the ability to 
directly browse the World Wide Web. Current devices 
provide Internet and World Wide Web access through a 
strictly modal interface, in which the user must select 
between using the wireless communication device in a 
browser mode, or in its native telecommunications mode for 
making telephone calls, accessing a stored telephone book, 
sending facsimiles, and the like. In the "browser mode" the 
user cannot dial a telephone number to make a telephone 
call; likewise in the telephony mode, the user cannot access 
a Web site. Thus, the user is unable to operate the wireless 
communication device in a seamless fashion that allows 
Web content to be downloaded and manipulated in context 
of the telephone functions, such as embedding an item of 
Web content that is obtained while browsing into the user's 
telephone book, or into an email message. 

[0015] Accordingly, it is desirable to provide an MMI in 
which Internet and World Wide Web access features are 
seamlessly integrated with the telephony and other controls 
of the wireless communication device so that user can access 
any feature of the wireless communication device at any 
time. 
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[0016] Software Engineering of the MMI 

[0017] Typically, an MMI is implemented as a module in 
a larger piece of code that manages the telephone control 
functions. The MMI is coded in the same computer language 
as the rest of the telephone control software. This makes the 
MMI difficult to modify without using the same program- 
ming skills and tools used to create the entire telephone 
control software. In other words, changing anything in the 
MMI requires the services of a skilled programmer familiar 
with the underlying telephony programming details and 
computer language. In addition, since the MMI is an integral 
part of the code for the telephone control software, imple- 
menting new changes in the MMI means compiling a new 
image of all the telephone control software, and testing the 
result to ensure that the new MMI features are compatible 
with all other code modules. In short, problems introduced 
by modifying the MMI software can potentially cause the 
handset to malfunction, disrupting service on the network to 
other users. Depending on the extent of the modifications, 
the change of any portion of the telephone control software 
can result in bugs, and/or the need for new type approval of 
the entire wireless communication device. Thus, it is desir- 
able to provide a software architecture which separates the 
design and implementation of the MMI functionality from 
the implementation of the telephone control software, allow- 
ing the manufacturer to quickly and safely customize the 
MMI design to suit the needs of a particular customer 

[0018] Customizing of the MMI for Service Operators: 
"Branding" 

[0019] In the wireless communication device industry, the 
services operators, such as cellular service providers, are 
interested in attracting and retaining their customers by 
aggressively branding their wireless communication device 
products, and offering new telephony features and network 
services to the user. Important among these are services that 
add value to the user, such as voice mail, electronic mes- 
saging, Internet access, and the like as mentioned above. 
"Branding" is the embedding of insignia, logos, or other 
indicia into the MMI of the wireless communication device 
and its features that identifies it to the consumer as origi- 
nating from the service operator. 

[0020] The manufacturers of the wireless communication 
device, who typically provide only the basic hardware 
components, must therefore provide a way for the service 
operator to integrate these features and services into the 
wireless communication device by software programming, 
and provide a mechanism for branding the features. A key 
problem is that these services are necessarily different in 
their functionality and requirements, and the task of provid- 
ing users with a current array of services and features is a 
difficult one. 

[0021] Wireless communication device manufacturers 
have traditionally attacked this problem by making a special 
version of the wireless communication device control soft- 
ware for each service operator selling that wireless commu- 
nication device in conjunction with its own communication 
services. Each specific version of the wireless communica- 
tion device contains the device manufacturer's branding, the 
operator's branding, and support for whatever features and 
services the service operator supports. Each of these ver- 
sions becomes a different piece of software to be tested, 
maintained, and modified as new features or services are 



provided to the consumer. This significantly increases the 
software development expense and maintenance issues. Fur- 
ther, unless the wireless communication device manufac- 
turer provides the service operator with the source code of 
the MMI and telephone control software, it requires the 
wireless communication device manufacturer to be directly 
involved in the branding and MMI design requirements of 
the service operator. Thus, it desirable to provide a software 
architecture for an MMI that allows the wireless communi- 
cation device manufacturer to provide a single body of 
telephone control software to each service operator, and 
allows each service operator to independently, and without 
the assistance of the wireless communication device manu- 
facturer, design, implement, and brand the MMI for the 
wireless communication device. 

SUMMARY OF THE INVENTION 

[0022] The present invention overcomes the various limi- 
tations of conventional wireless communication devices by 
providing a wireless communication device with an MMI 
that is based on a markup language. A markup language is 
a computer programming language that allows the content of 
a page or a screen display to be defined by the inclusion of 
predefined symbols in the content itself indicating the logi- 
cal components of the content, instructions for the layout of 
the content on the page or screen, or other data which can be 
interpreted by some automatic system responsible for dis- 
playing, manipulating or modifying the content. 

[0023] In one aspect the present invention provides a 
wireless communication device including a user interface 
defined in a markup language. To effect this, the present 
invention includes a markup language browser that it uses to 
provide both telephony control of the wireless communica- 
tion device, in response to user selection of telephony 
functions in the user interface, and Internet access via the 
HyperText Transport Protocol (HTTP), in response to user 
selection of data items associated with content located on the 
Internet. 

[0024] In one embodiment, the telecommunication control 
and other functions of the wireless communication device 
are defined in various user interface pages written in a 
markup language. Each control function is associated with, 
or activated by a Uniform Resource Locator (URL). A URL 
is a data item specifying a protocol for obtaining a data item, 
and which data item should be fetched or manipulated. The 
user interface pages are stored in a local memory of the 
wireless communication device, and fetched by the browser, 
which decodes them and displays the appropriate user 
interface elements. The browser can also modelessly fetch 
markup language pages or other content that is stored 
remotely, by accessing such pages via a telecommunications 
network such as the World Wide Web, and likewise decode 
and display these remotely accessed pages. When a user 
interface page is displayed, user selection of a control 
function passes a URL or command data to the browser. The 
browser effects a telecommunication function in response 
the received URL or command. 

[0025] The browser preferably includes a number of pro- 
tocol handlers, including a telephony protocol handler, a 
local file protocol handler, and an remote file protocol 
handler, and a number of content handlers, including a 
markup language handler. The telephony protocol handler 
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decodes URLs for telephony control features such as tele- 
phone dialing and answering, and activates underlying func- 
tions of telephony control software controlling the hardware 
of the wireless communication device. Any content of the 
URL that is needed to display the telephony controls is 
provided to the markup language content handler, which 
parses the content and displays it on a screen display. The 
markup language content handler is generally responsible 
for displaying any fetched markup language pages, includ- 
ing all user interface pages, and for receiving user inputs to 
these pages via forms and other input means. 

[0026] The markup language handler generally receives 
content from two sources, the local file protocol handier and 
the remote file protocol handler. The remote file protocol 
handler decodes URLs for accessing content on the World 
Wide Web, and provides the fetched content, such as a Web 
page, form, applet, or the like to the markup language 
content handler for outputting the content to the screen 
display of the wireless communication device. One suitable 
remote file protocol handler implements HTTR The local 
file protocol handler decodes URLs for accessing local user 
interface files and provides such content to the markup 
language content handler. In a preferred embodiment of the 
MMI, the user interface is defined in HyperText Markup 
Language, or "HTML/' and the browser includes a HTML 
content handler that displays both Web content and user 
interface featured defined in HTML. 

[0027] The use of a markup language to define the MMI 
of a wireless communication device provides numerous 
advantages over conventional MMI software architectures. 
First, the use of a markup language allows for complete and 
seamless integration of Internet and World Wide Web access 
into the telephony and other features of the wireless com- 
munication device. Since the MMI uses a markup language 
such as HTML to display all the functional screens, the 
World Wide Web content (which is also written in HTML) 
has the same appearance as other features of the wireless 
communication device. More particularly, the pages of the 
MMI are accessed using URLs, just as Web content is 
similarly accessed. When displaying a functional page the 
wireless communication device accesses a local URL; when 
displaying Web content, the wireless communication device 
automatically initiates a connection with a Web server to 
obtain the Web content. The markup language based MMI 
thus allows for a modeless user interface that enables the 
user to access the Internet and the World Wide Web at any 
time, without having to switch the wireless communication 
device between telephony and "browser" modes, as in 
conventional devices. 

[0028] As a further benefit of the markup language based 
MMI, Web content such as Web pages, forms, and the like, 
from the World Wide Web can be accessed and incorporated 
directly into telephony, messaging, and other non-Internet 
based features of the wireless communication device. For 
example, in a preferred embodiment, a wireless communi- 
cation device has a telephone book of stored telephone 
numbers and names. Conventionally, the user would have to 
manually key these entries in using the keypad of the 
wireless communication device. In a wireless communica- 
tion device using an MMI in accordance with the present 
invention, the user could add an entry to the telephone book 
simply by accessing a telephone directory on the World 



Wide Web, which can contain HTML that allows the user to 
easily store the information directly into the telephone book. 

[0029] The use of a markup language also reduces the 
complexity of the software engineering process for creating 
the MMI for a particular wireless communication device. 
First, since the MMI of the present invention is based on a 
markup language, only a very limited amount of program- 
ming skill is needed to design a fully featured user interface, 
unlike a conventional MMI which requires a programmer 
skilled in C or other low level language programming. 
Editing and modifying the user interface requires only 
simple markup language and image editing tools, not a 
complete application programming environment. Second, 
using the markup language based MMI of the present 
invention enables any of the features the MMI to be modi- 
fied, without having to re -compile the entire telephone 
control software, and re -test and certify the entire package. 
Because the MMI is separate from the underlying telephone 
control and air interface stack, only user interface pages that 
are individually changed or added need to be tested. This 
reduces the time to market, and increases the ease of 
designing, maintaining, and modifying the MMI as new 
features and services become available. Reduction of the 
time to create and test changes in the user interfaces also 
means that more different versions can be prototyped in less 
time than with a conventional MMI, thereby facilitating 
design exploration for the best user interface design for a 
given set of user requirements and features. 

[0030] The ease with which the user interface of a MMI 
can be created and modified, and the reduction of time to 
market further enables the service operator to quickly gen- 
erate wireless communication devices targeted at specific 
customer segments, without requiring the device manufac- 
turer to create specific product software images for each and 
every target customer segment. For example, the service 
operator may use the same wireless communication device 
hardware and telephony control software with different user 
interfaces designed for executives, teen-agers and seniors, 
each of whom may have different needs and abilities to use 
the features of the wireless communication device. 

[0031] For example, using a markup language to define 
the pages of the user interface allows any of the following 
items to be changed on any page: title bar presence and text; 
all informational text; option list text; links to all subsequent 
screens; soft key assignments; permanent scrolling banner 
messages; banner advertising; and help text. 

[0032] The use of markup language based MMI also 
provides advantages in the branding of the wireless com- 
munication device for different service operators. Since the 
user interface is defined in markup language pages, service 
operator-specific logos, artwork, and text can be easily 
added and changed by individual service operators. Thus, 
the wireless communication device can provide the same 
wireless communication device hardware and telephone 
control software to a number of service operators, each of 
whom can quickly and easily brand the wireless communi- 
cation device with their own distinctive user interfaces, 
without requiring the wireless communication device manu- 
facturer to implement, test, and ship different user interfaces 
to each operator, as is conventional. 

[0033] In providing a wireless communication device with 
a markup language based MMI, the present invention 
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enhances the standard HTML with a number of extensions 
that make it particularly useful for working with wireless 
communication devices. Standard HTML assumes the pres- 
ence of a conventional computer with keyboard, pointing 
device, and full size display screen, features which are not 
present in most wireless communication devices. The most 
notable deficiencies of HTML include: 

[0034] Form elements (e.g., checkboxes, radio but- 
tons) are awkward to navigate without a mouse, 

[0035] Forms as they exist in content today tend to be 
too large for the user to maintain some context as she 
is filling them in on a small screen. If the form is 
divided into n forms, then the user's input is sent 
between the client and the server and back to the 
client n-1 times, wasting bandwidth. In addition, 
with a series of smaller forms, terminating the trans- 
action could be tortuous as the user hits the back key 
for each form in the series. 

[0036] Hyperlinks are awkward to follow without a 
mouse to select them and a separate scrollbar for 
scrolling the content of a page. On a device with only 
an Up key and a Down key to both select which 
hyperlink to follow and to scroll the display, fixed 
assignment of either scrolling or selecting to the Up 
and Down keys is insufficient to provide the needed 
navigational abilities. 

[0037] As a user interface definition language, HTML 
lacks a number of key features: 

[0038] The ability to specify actions for the soft 
function keys, or indeed for any key on the device. 

[0039] The ability to define a pop-up menu of 
choices. 

[0040] The ability to display or alter the data one 
would like to store on the device, such as names and 
phone numbers. 

[0041] The ability to design a screen as a template 
without writing C code to fill in the blanks. 

[0042] The ability to allow content arriving over the 
air to extend or customize the interface the device 
presents to the user. 

[0043] The present invention provides extensions to the 
HTML language which facilitate the design of multi-part 
forms, the use of a limited number of keys to both navigate 
Web pages and select hypertext links, define actions for any 
key (keypad or softkey) of the wireless communication 
device using URLs, create menus of options for softkeys, 
and conditional inclusion of text, formatting, and user inter- 
face gadgets. 

[0044] More particularly, the present invention provides a 
"key" tag that allows the assignment of specific functions or 
actions to any key of a key-pad, including binding a menu 
to a key. A "keymenu" tag allows specification of the menu 
items to be included in a menu bound to a key. A "template" 
tag and an "include" tag allow for the substitution or 
insertion of external HTML or other data directly into the 
HTML of a page. A "help" tag allows for the definition of 
help strings that are automatically scrolled across the title 
bar of page after a set time period. A conditional tag allows 
for the testing of expressions to conditionally display HTML 



data within a page, for example based on variables or 
configuration settings of the device. A "next" method for 
forms allows for maintaining state of a multi-part form 
without having to repeatedly transmit hidden data between 
a client and server to maintain the state. Improved naviga- 
tional methods allow for the Up and Down keys of a wireless 
communication device to control both scrolling of a page, 
and selection of user interface gadgets and hyperlinks, in the 
absence of separate Tab and Enter keys and scroll bars. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0045] FIG. 1 is an illustration of the top level software 
and system architecture of a wireless communication device 
in accordance with the present invention. 

[0046] FIG. 2 is an illustration of a sample user interface 
page for a wireless communication device is accordance 
with the present invention. 

[0047] FIG. 3 is an illustration of the detailed software 
architecture of a man-machine interface of a wireless com- 
munication device in accordance with the present invention. 

[0048] FIG. 4 is an illustration of the URL history stack. 

[0049] FIG. 5 is a flowchart of the operation of the shell 
in handling received URLs. 

[0050] FIGS. 6a and 6b are a flowchart of the operation of 
the HTMLp content handler in processing a string input 
associated with a user interface gadget 

[0051] FIG. 7 is an example HTMLp file and page show- 
ing a key menu using the <KEY> and <KEYMENU> tags. 

[0052] FIG. 8 is an example HTMLp file and page show- 
ing a help text scrolling banner with the <HELP> tag. 

[0053] FIG. 9 is an example HTMLp file and page show- 
ing the use of the <TEMPLATE> tag for template files. 

[0054] FIG. 10 is an example HTMLp file and page for 
editing a phone book. 

[0055] FIG. 11 is another example HTMLp file and page 
for editing a phone book. 

[0056] FIG. 12 is an example HTMLp file and page 
showing the use of expressions for evaluating the 
CHECKED and SELECTED attributes. 

[0057] FIG. 13 is an example HTMLp file and page 
showing included HTML with the <INC> tag. 

[0058] FIG. 14 is an example HTMLp file and page using 
the PHONENUM and PHONENAME attributes for the 
<INPUT> tag. 

[0059] FIG. 15 is a flowchart of the process for handling 
an input key by the HTMLp content handler. 

[0060] FIG. 16 is an example conventional HTML file and 
page for a complex form. 

[0061] FIGS. 17a.l-17&2 are example HTML files and 
pages showing a conventional multiple form approach using 
HIDDEN input data. 

[0062] FIGS. 18a.l-18i>.2 are example HTMLp files and 
pages showing a multi-part form used with the NEXT 
method. 
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[0063] FIG. 19 is an example HTMLp file and page 
showing the default creation of a menu of hyperlinks with- 
out the use of the <LINKMENU> lag. 

[0064] FIG. 20 is an example HTMLp file and page 
showing the use of the <LINKMENU> tag. 

[0065] FIGS. 21a-21e illustrate various user interface 
pages for dialing a telephone number. 

[0066] FIGS. 22a -22c illustrate various user interface 
pages for handling active calls. 

[0067] FIG. 23 is an example HTMLp file and page 
showing the use of the "extra" protocol. 

[0068] FIG. 24 is a table of icons and images used with the 
builtin protocol. 

[0069] FIG. 25 is an example HTMLp file and page 
showing the use of the <DIAL> tag. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

[0070] A. System and Software Architecture 

[0071] Referring now to FIG. 1, there is shown an illus- 
tration of the system and software architecture of a wireless 
communication device 100 using the markup language 
based MMI 102 in accordance with the present invention. 
The hardware of the wireless communication device 100 
includes a processor 124, memory 126, screen display 136, 
and keypad 128. Memory 126 includes ROM, RAM, and a 
flash memory for long term storage of data. A suitable 
wireless communication device 100 for providing the hard- 
ware features is a Nokia 6100™ manufactured by Nokia 
Telecommunications, Inc. 

[0072] The wireless communication device 100 stores in 
the memory 126 and executes a conventional real time 
operating system 122, which includes modules for managing 
power, memory, threads (communication connections), key- 
pad inputs, and timer activities. The real time operating 
system 122 provides a standard application programming 
interface to allow higher level components of the MMI 102 
to request functionality of the wireless communication 
device 100, and to send and receive data. 

[0073] Also stored in the memory 126 and in communi- 
cation with the real time operating system 122 is telephony 
control module 120 that provides the primary telephone 
controls, including making and receiving telephone calls, 
managing multiple telephone lines (if appropriate), manage- 
ment of text messaging (if appropriate), monitoring of 
telephone signals, and other basic telephony functions. The 
telephony control module 120 includes a conventional tele- 
phone protocol stack that implements an air-interface pro- 
tocol. The telephony control module 120 provides an appli- 
cation programming interface to the MMI 102 to access 
these features. The telephony control module 120 and the 
real time operating system 122 are typically provided by the 
manufacturer of the wireless communication device 100, 
and their particular implementation is not material to the 
invention. 

[0074] The screen display 136 is a bitmapped LCD or 
similar display device. The screen display 136 is typically of 
very limited resolution, for example about 90x60 to 120x 
120 pixels (at about 0.28 mm dot pitch) as would be 



appropriate for a compact, portable, hand-held electronic 
device. It is anticipated that advances in display technology 
will result in screen displays 136 of significantly higher 
resolution, but even so, the ergonomic and form factor 
requirements of wireless communication devices will result 
in screen displays that are relatively small (e.g., between 
25x25 mm and 80x120 mm) as compared to the screen 
displays of notebook and desktop computers, and as a result 
will not display content designed for such larger screen 
displays in the exactly the same manner. The present inven- 
tion is adapted to increase the ease of use of such screen 
displays when displaying Web content. 

[0075] The wireless communication device 100 has a 
keypad 128 that includes a number of fixed function keys 
132 for accessing defined functions of the wireless commu- 
nication device 100 (e.g., "Send,""End/' and "Power"), 
number keys 134 for entering digits (and if suitably encoded, 
for entering other characters), and programmable softkeys 
130 which have variable functionality that changes depend- 
ing on the particular screen display of the user interface 104 
being shown. 

[0076] The wireless communication device 100 stores in 
its memory 126 and executes an instance of an MMI 102 
made in accordance with the present invention. This MMI 
102 includes a set of user interface definition files 104, a 
browser 107, a set of portable components 116, and a 
portability layer 118. The browser 107 provides the primary 
user interface mechanism to the user, allowing access to both 
telecommunication functions, and InternetAVorld Wide Web 
access. The portable components 116 provide a set of 
graphics primitives, file store functions, and localization 
features that allow the browser to be used on a variety of 
wireless communication devices 100. The portability layer 
118 provides an interface for the browser 107 and portable 
components 116 to the real time operating system 122 and 
the telephone control module 120. 

[0077] The MMI 102 executes as a single-threaded appli- 
cation, and is generally designed to run on any real time 
operating system 122, telephone control module 120, and 
wireless communication device 100 that provides sufficient 
ROM, RAM, and flash memory, a screen display 136, and 
basic services. 

[0078] B. The Browser 

[0079] The browser 107 provides the basic user interface 
of the wireless communication device 100 and is responsible 
for displaying content on the screen display 136, as defined 
by the user interface definition files 104, and as may be 
retrieved from remote sites, such as Web content accessed 
via a communication link to a remote Web site. The user 
interface definition files 104 are a set of content and code 
files written in a markup language such as HTML, or the 
preferred variant described below, HTMLp, and may include 
executable embedded code objects. The present invention is 
not limited to HTML, but also operates with, and may 
extend any other markup language, such as SGML, or XML, 
or other extended non-standard versions of HTML, such as 
the Netscape Communications* set of HTML extensions. 

[0080] Since each service operator providing a wireless 
communication device using the MMI 102 of the present 
invention will design their own specific user interface, 
typically modifying some portion of the user interface 
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definition files 104 provided by the device manufacturer, the 
particular content of the user interface definition files 104 is 
variable, and expected to be different from any of the 
illustrative user interface screens described herein. In addi- 
tion, it is expected that the MMI 102 may be provided to a 
service operator without any user interface definition files 
104 at all, leaving the service operator to create these files 
as desired; thus the user interface definition files 104, while 
used by the MMI 102 of the present invention, themselves 
are not an essential part of the invention. As the user 
interface definition files 104 define the user interface pre- 
sented to the user, they allow the service operator to easily 
and quickly 'brand' the wireless communication device 100, 
by simple editing of the user interface definition files 104. 
This branding requires no recompilation of the underlying 
browser 107, portability layer 118, or portable components 
116, and thereby makes customization very easy and cost 
effective. It also means that the service operator can cus- 
tomize and brand the user interface using simple markup 
language editing tools, without necessitating the program- 
ming skill and environment of conventional code develop- 
ment. 

[0081] Following the terminology of the World Wide Web, 
an individual user interface screen is herein called a "page." 
Referring now to FIG. 2, there is shown a basic layout of a 
page 135 displayed on the screen display 136 by the browser 
107. Each page 135 generally has four basic areas. A status 
bar 200 that is preferably always present and displays items 
such as signal strength 202 and battery strength 204, mes- 
sage-waiting indicator 206. A title bar 210 displays the name 
for a particular screen, if so defined. A status message area 
212 may be used to present status messages particular to the 
current content, such as a telephone number being called or 
aaswered. A content area 214 is used to display the particular 
content of a user interface page, for example, text of a 
message, phone book entries, and the like. Along the bottom 
(though other locations may be used) are softkey labels 216, 
which are dynamically updated according to key definitions 
provided in the user interface definition files 104. A scroll 
arrow 215 indicates the current direction in which the user 
is scrolling (either up or down). In the content area 214, a 
focus and selection icon 220 may optionally be used to 
indicate the particular item or line of content that has the 
focus, i.e. is the current user interface gadget or input field. 
A mode indicator 218 indicates the mode for text entry, 
whether alpha, numeric, or a combined alphanumeric mode. 

[0082] Any of the pages or content displayed on the screen 
display 136 may be obtained locally from the user interface 
definition files 104 or remotely from the Internet or World 
Wide Web. Examples of local content include a telephone 
book, received text messages, or messages being created for 
sending, configuration settings for the wireless communica- 
tion device, and the like. One of the features of the present 
invention is that whether the content is locally or remotely 
fetched is largely hidden from the user, except for the delay 
(if any) in obtaining it. This feature enhances the presenta- 
tion of seamlessly integrated Internet and World Wide Web 
access with telecommunication functions. 

[0083] Most of the features of the user interface are 
activated by means of a URL (Universal Resource Locator). 
Nominally, a URL is a means of identifying a piece of data, 
which data may be predefined, or may be generated on 



demand based on arguments that are encoded in the URL. A 
URL is a string that takes the following form: 

[0084] protocol:data-identifier[?arguments] 

[0085] The protocol component specifies a communica- 
tion protocol that should be used to retrieve the data. For 
content located on the World Wide Web, the protocol is 
usually "http" for the HyperText Transport Protocol; local 
content of the user interface definition files 104 is retrieved 
with the "file" protocol to obtain data in a local file system 
stored in the memory 126. The present invention provides a 
number of additional new protocols that control the opera- 
tion and configuration of the wireless communication device 
100. 

[0086] The data- identifier component is a specification of 
the desired content to be fetched. Currently, for content on 
the World Wide Web, the data-identifier normally takes the 
form of two V characters, followed by a machine name, 
another 7 J character, and a path of some sort. 

[0087] The arguments, if present, are separated from the 
data-identifier by a 'V and take the form of pairs made of an 
argument name and its value. An character separates an 
argument name from its value. Multiple arguments are 
separated by an character between the value of one and 
the name of the next. 

[0088] Architecturally, the browser 107 includes three 
major pieces: shell 106, protocol handlers 112, and content 
handlers 114. FIG. 3 illustrates the detailed software archi- 
tecture of the MMI 102, including browser 107. 

[0089] The shell 106 is responsible for maintaining the 
universal parts of the screen display 136, for processing 
URLs by passing portions of a URL to the correct protocol 
112 and content handler 114 for the URL, for maintaining a 
history stack 108 of URLs, and for routing user input. User 
input routing involves passing user input keystrokes to the 
appropriate content handler 114 or other target entity for 
processing, such as entering input numbers and letters into 
a form, or dialing a telephone number. 

[0090] Protocol handlers 112 receive a URL from the shell 
106, and are responsible for fetching the data corresponding 
to the URL, and instructing the shell 106 which content 
handler 114 should receive the data. In some cases, the URL 
is a command to control features of the wireless communi- 
cation device 100, which the protocol handler 112 is respon- 
sible for executing. 

[0091] Content handlers 114 are responsible for displaying 
fetched URL data and interacting with the user. At least one 
content handler 114 is always the current content handler 
114. It is from the current content handler that any new URL 
is provided back to the shell 106, and that receives by default 
any keystrokes that are not delivered to any other input 
target. The shell 106 is further described below with respect 
to FIGS. 4-5. 

[0092] 1. Overview of the Protocol Handlers 

[0093] The protocol handlers 112 serve two functions in 
the MMI 102: First, they fetch data and determine its type; 
the determination of type in turn determines which content 
handler is used to display the data. Second, they perform a 
command in the wireless communication device 100, by 
accessing an embedded object or the appropriate API of the 
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real time operating system 122, or telephone control module 
120, A protocol handler 112 may return the results of that 
command, causing a different screen to display, or may 
return no results. The protocol handlers 112 of a preferred 
embodiment include the following. 

[0094] Builtin protocol handler 112a provides access to 
icons that are built in to the wireless communication device 
100. 

[0095] Config protocol handler 112b gets and sets con- 
figuration settings of the wireless communication device 
100. 

[0096] Extra protocol handler 112c provides access to 
arguments and form data that are passed from an embedded 
object in a page, or from previously accessed pages. This 
protocol allows data to be passed directly into a page, 
without requiring the page to be dynamically generated. 

[0097] File protocol handler 112d provides access to local 
content in ROM and in the flash file systems. Generally, this 
content is user interface definition files 104 that define the 
pages of the user interface. The file protocol handler 112d 
may be implemented by those of skill in the art according to 
a suitable specification for file system access, such as the 
POSIX specification. 

[0098] HTTP hander 112e is a remote file protocol handler 
that provides accesses to remote content stored on the 
World-Wide Web, using the standard HyperText Transfer 
Protocol. The HTTP handler H2e may be implemented by 
those of skill in the art according to the specification defined 
in RFC 2068: Hypertext Transport Protocol— HTTP/1.1. 
Other remote file access specifications may also be used to 
implement a remote file protocol handler. 

[0099] Message protocol handler 112/ activates various 
messaging functions, including sending a message, deleting 
a stored message, reading new or stored messages, or 
locking a stored message. 

[0100] Telephone protocol handler 112g activates various 
telephone functions, including making a call, answering an 
incoming call, displaying the phone book, editing a phone 
book entry, and creating a new phone book entry. 

[0101] Config protocol handler 1126 (shown as part of the 
portability layer 118) retrieves and sets various configuration 
settings for the wireless communication device 100. 

[0102] a) Basic Protocol Handler API 

[0103] Generally, a protocol handler 112 is similar to a 
device driver, in that it has a well-defined set of functions it 
can perform, and each protocol handler 112, though sup- 
porting the same functions, supports those functions in its 
own manner. Each protocol handler 112 implements three 
functions: 

[0104] GetURL: Given a URL and a security level of the 
page containing the URL to be fetched, returns the data 
associated with the URL, and the privilege level of that data. 
If the URL is actually a command, rather than a reference to 
data, no data need be returned. 

[0105] BuildURL: Given a fall URL and a partial URL 
(without the protocol: element), returns a full URL. This is 
used primarily for references inside HTML pages. 

[0106] PutURL: Given a URL, a stream of data to be 
stored under the URL, and the security level of the page 



containing a "put" method, stores the data if the security 
level is high enough to allow it. 

[0107] The various embedded object and command URLs 
supported by the protocol handlers 112 are described below. 

[0108] 2. Overview of the Content Handlers 

[0109] Content handlers 114 are responsible for decoding 
the content data of a page corresponding to a fetched URL 
and displaying the content, or otherwise manipulating the 
content. A content handler 114 typically decodes content it 
receives and presents a page in the screen display 136, or 
portion thereof. Some content handlers 114 construct the 
page from data they receive from the memory 126 or over 
a communications link, while others display the state of the 
wireless communication device 100 or serve some other 
administrative function. In a preferred embodiment of the 
browser 107, the content handlers 114 include the following: 

[0110] CallManager content handler 1146 manages an 
incoming call screen defined in the user interface definition 
files 104 to enable the user to receive incoming calls. The 
CallManager content handler 1146 provides other function- 
ality through embedded objects. 

[0111] HTMLp content handler 114c displays the bulk of 
the user interface by accessing the appropriate user interface 
definition files 104 in memory 126. The HTMLp content 
handler 114c includes a HTML 3 2 compatible parser, and is 
capable of decoding HTML and creating the necessary data 
structures and objects to display text and graphics according 
to HTML tags. In addition, the HTMLp content handler 114c 
accepts a modified form of HTML 3.2, herein called 
"HTMLp" as described below, which provides a number of 
beneficial extensions to the features and functionality of 
HTML 3.2. 

[0112] To better serve as a user interface, and provide 
added flexibility in designing the user interface, the HTMLp 
content handler 114c allows objects, written in C or other 
programming language, to be embedded in an HTML or 
HTMLp page to display different types of data that are in the 
wireless communication device 100. However, the HTMLp 
content handler 114c, unlike a standard HTML parser, first 
passes user selected URLs in a current page to any embed- 
ded object, allowing the URL to be modified by what the 
user has selected or entered or fully processed before they 
are given to the shell 106 to process. 

[0113] In the preferred embodiment, the available embed- 
ded objects include the following: 

[0114] A phone book object stores records of names, 
associated telephone numbers, addresses, email addresses, 
speed dial key selection, ring tone, and other definable fields 
of data. The phone book object includes methods to get and 
set the fields of records. A phone book object may be 
embedded in a page and activated by the appropriate URL 
of the phone protocol, 

[0115] A recent and missed phone call list object stores a 
continually updated list of telephone numbers that were 
recently called, received, or not answered. The call list 
object includes methods to delete and dial a telephone 
number on the list. The call list may be embedded in a page 
and activated by the appropriate URL of the phone protocol. 

[0116] A speed dial number list object stores a set of 
telephone numbers and associations to keys of the keypad 
128, such that the selection of the key provides for speed 
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dialing functionality. This list object include methods to set, 
get, and dial a speed dial number. 

[0117] A phone number lookup object accesses the phone 
book object to return a telephone numbers) associated with 
an input or selected name or name fragment. 

[0118] A phone book name lookup object accesses the 
phone book object to return a name(s) associated with an 
input or selected telephone number of number fragment. 

[0119] A list object of text messages/alpha-numeric pages 
that have been received or sent. The message list object 
stores a list of messages, including email or Short Message 
Service messages, and includes methods to view, store, edit, 
delete, and send messages. The message list may be embed- 
ded in a page and activated by the appropriate URL of the 
message protocol. 

[0120] The main content handler 114d is primarily a 
front-end for the HTMLp content handler H4c in that it uses 
HTMLp to display a main screen for the wireless commu- 
nication device 100. 

[0121] The advert content handler 114a is a front-end for 
the HTMLp content handler 114c that chooses which adver- 
tising page to display when the wireless communication 
device 100 is idle and instructs the HTMLp content handler 
114c to display it. In addition, it intercepts keystrokes and 
user interface gadget activation to optionally delete an 
advertisement that has been responded to or expired. 

[0122] a) Basic Content Handier API 

[0123] Like protocol handlers 112, content handlers 114 
have a well-defined interface the shell 106 uses to commu- 
nicate with them. The interface is tailored around the screen 
display 135 in the sense that there the content area is defined 
within the screen display and interaction needs of content 
handlers 114. The four functions each content handler 114 
supports are: 

[0124] ContentOpen: This is the call that gives a content 
handler 114 control of the content area 214 of the screen 
display 136, the softkeys 130 and softkey labels 216, title bar 
210, and status message area 212. Each content handler 114 
receives the following four pieces of information when its 
ContentOpen function is invoked: 

[0125] 1. A stream of data returned by the protocol 
handler 112 that fetched the data; this is data to be 
displayed. 

[0126] 2. A handle to the content area 214, indicating 
where the data is to be displayed. 

[0127] 3. A flag indicating whether the content han- 
dler 114 has previously displayed this data. 

[0128] 4. A pointer to extra data that was passed by 
whatever entity asked the shell 106 to fetch the URL, 
allowing the extra data to be entered into the page 
being displayed. The use of the extra data is further 
described below with respect to the <TEMPLATE> 
tag of HTMLp, and the "extra" protocol. 

[0129] ContentClose: When the user asks to close a page, 
or asks to open a different page, the current content handler 
114 is closed. It receives a flag that indicates whether the 
page is maintained in the URL history stack 108, or if it has 
been removed from the stack permanently. 

[0130] ContentProcessKey: In the absence of anything 
else to process a keystroke, the shell 106 delivers the 



keystroke to the current content handler 114 by default. The 
current content handler 114 is the one displaying the content 
whose URL is at the top of the URL stack. 

[0131] ContentActivate: When the user presses a softkey 
130 or selects an item from a menu, the string that is bound 
to the key or menu item is passed to the current content 
handler 114 via this function. In some cases, the string will 
be a URL that can be passed straight to the shell 106 to be 
fetched. In other cases, the string is an indication of what the 
user wishes to do, and the content handler 114 may perform 
the action itself, or it may use an item the user has selected 
on the screen display 136 to generate a URL it can give to 
the shell 106. For example, if the user selects an entry in the 
phone book and presses a softkey 130 labeled "Edit", the 
HTMLp content handler 114c will take the string associated 
with that softkey 130 and pass it to the embedded phone 
book object, which will use the string as a template for 
generating the actual URL to pass to the shell 106, based on 
which phone book entry the user has selected in the embed- 
ded object. 

[0132] The specific functionality of the content handlers 
114 is further described below. 

[0133] 3. Control Flow 

[0134] A preferred implementation of the browser 107 is 
organized around a single callback queue 110, which takes 
the place of the event loop used in other environments. Any 
part of the MMI 102, can request that a function be called 
at a later time by adding a function request to the callback 
queue 110. 

[0135] The callback queue 110 has a number of elements, 
each of which has a pointer to a function to call, and two 32 
bit arguments to pass to the routine. The function pointer can 
be to any module in the system. 

[0136] Essentially, the overall system executes a top most 
control loop: 

[0137] 1. Call the next item on the callback queue 
110. 

[0138] 2. Update the screen display 136 with any 
changes that call made. This step includes drawing 
graphical elements to the screen (e.g. scrolling, 
updating status messages and icons) displaying key- 
strokes, and displaying new pages in response to user 
activation of functions or features associated with 
URLs. 

[0139] 3. Go to step 1. 

[0140] Items for the callback queue 110 are added prima- 
rily by asynchronous events such as keystroke (up or down), 
change in an active call, timer expiration, and incoming text 
messages. 

[0141] Certain protracted operations also will use the 
callback queue 110 to continue the operation, while still 
allowing other actions (such as user input) to be handled. For 
example, reading the frames of an animated GIF image is 
broken into two conceptual phases: 

[0142] L Read the first frame and queue a call to read 
the next frame. 

[0143] 2. Attempt to read the next frame. If success- 
ful, queue a call to read the next frame. 

[0144] In this way, a page containing the animation can be 
displayed as soon as possible while the rest of the animation 
is effectively loaded in the background. 
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[0145] 4. The Shell 

[0146] The shell 106 provides handling of input key- 
strokes and other inputs from the lower layers, and passing 
of such inputs to the appropriate protocol handlers 112 and 
content handlers 114. A list of shell 106 functions is pro- 
vided in Appendix A. 

[0147] a) Keypad Input 

[0148] Keypad input arrives spontaneously at the shell 106 
from the portability layer 118. The shell 106 maintains a 
keystroke target list which is a list of entities, particularly 
user interface objects of the currently displayed page, that 
can process the keystroke. When a keystroke arrives, the 
shell 106 passes the keystroke to the first entity in the 
keystroke target list, via ShellProcessKey. If that entity 
decides not to process the keystroke, it calls the shell 106 to 
give the keystroke to the next entity in the list (ShellPrevi- 
ouslnput). The final entity in the list, placed there by the 
shell 106 when the list is initialized, disperses the keystroke 
to the current content handler 114, which can choose to pass 
to a default processing routine in the shell 106 that imple- 
ments system-wide keystroke defaults, or the current content 
handler 114 can handle the keystroke as desired. 

[0149] The shell 106 includes functions to register an 
entity (usually a user interface object) into the keystroke 
target list (ShellGrablnput) and release an entity from the list 
(ShellReleaselnput). 

[0150] b)Softkeys 

[0151] One type of key that has a special function is a 
softkey 130, which is a key whose label is displayed on a 
page in the screen display 136, and whose purpose changes 
from page to page, according to defined parameters in the 
user interface definition files 104. The shell 106 manages a 
number of softkeys 130, typically between one and three, 
but variable depending on the wireless communication 
device 100. Each softkey 130 may be bound to a string, or 
to a menu whose menu items specify a string, or the softkey 
130 can be set to pop one or more entries from the URL 
stack, or to do nothing. 

[0152] When a softkey 130 or a menu item that is bound 
to a string is activated, the string is passed to the current 
content handler 114 via its ContentActivate function. In 
some cases, the string that is bound to a softkey 130 is a URL 
to be fetched. In this instance, the URL is passed by the 
content handler 114 to the shell 106 for processing 
(ShellGetURL) and fetching by the appropriate protocol 
handler 112 and content handler 114. In other cases, the 
bound string is a command that the content handler 114 
handles itself without changing pages. Finally, the bound 
string may be a mixture of the two: a template URL (see 
below) that is modified by the content handler 114, based on 
some input from the user, before being fetched. 

[0153] As noted above, as part of its ContentActivate 
function, the HTMLp content handler 114c passes a string 
bound to a user selected user interface entity to any embed- 
ded object in the current page before it examines the string 
itself. Some embedded objects simply take commands to 
operate on what data they are displaying in this way, while 
others look for special escapes in the string to substitute 
some portion of the data the user has selected, yielding a 
URL that they then pass to the shell 106. The HTMLp 
content handler 114c also has certain special commands it 
accepts, rather than just accepting URLs from hyperlinks. 



[0154] c) URL Processing 

[0155] The step of updating the screen display 136 in the 
above described control flow, when done in the context of 
obtaining a new page for display, is accomplished by passing 
a URL to the shell 106 via the ShellGetURL function. FIG. 
4 illustrates the URL history stack 108 used by the shell 106 
to support URL processing. The URL history stack 108 is a 
LIFO stack. Each entry 402 includes a URL 404, a pointer 
406 to a function table 412 for functions for the particular 
content handler 114 that handles the URL, extra data 408 (if 
any) that was passed in with the URL to be retrieved by the 
"extra" protocol or to be used by the content handler for the 
URL, a pointer 410 to the next URL, a privilege level 414 
at which the page is operating, the priority 416 of the URL, 
and a pointer to the state block 418 the shell 106 maintains 
on behalf of the content handler 114. 

[0156] Referring to FIG. 5 there is shown a flowchart of 
the operation of the shell 106 in handling a URL. The shell 
106 extracts 500 the first part of the URL string, before the 
first V character, and compares 502 it to the list of known 
protocol handlers 112 to identify the appropriate handler for 
fetching the URL data. If no protocol handler 112 is found, 
then the shell 106 creates 508 a complete URL by calling the 
BuildURL function of the protocol for the URL currently at 
the top of the URL stack, passing it the current top URL and 
the URL that is being fetched. The protocol handler 112 
returns the absolute URL that should be used in place of the 
relative one that was passed in. 

[0157] If a protocol handler 112 is found, the shell 106 
calls 504 the GetURL function of this protocol handler 112, 
passing the remainder of the URL. The protocol handler 112 
is expected to fetch the URL, and return a pointer to a 
ContentStream structure that includes a string indicating the 
type of data returned, the privilege level at which the data 
should be interpreted, and a pointer to a Stream, which 
contains the actual data (the data need not be present yet, but 
reading from the stream must return the data as it arrives). 
If no stream is returned 506, the shell 106 returns 510 an 
error. 

[0158] The shell 106 matches 512 the data-type string 
against the list of known content handlers 112. If there is no 
match, the shell 106 returns 520 an error. If there is a match 
514, this content handler 114 becomes the current content 
handler. The shell 106 resets 516 the softkeys 130, content 
area 214 size, title bar 210, and status message area 212 to 
their default state. The shell 106 invokes the ContentOpen 
function of the current content handler 114, passing both the 
ContentStream and control of the content display area 214 to 
the current content handler 114 for the content to be dis- 
played. 

[0159] If the open call is successful 522, the shell 106 
updates the URL history stack 108, placing the URL, the 
pointer to the current content handler 114 functions, any 
extra data, on the stack, and returns 524 success to the entity 
requesting the URL, otherwise, the shell 106 reopens 526 
the previous URL from the URL history stack 108, and 
returns an error. 

[0160] 5. Security 

[0161] Because content that is received over the air is 
allowed to activate telephone features and access telephone 
data, such as telephone book entries, the present invention 
provides mechanisms for security to prevent unauthorized 
access to functions or data. 

[0162] When a URL is fetched by a protocol handler 112 
as part of its GetURL function, its data are assigned a 



06/10/2004, EAST Version: 1.4.1 



US 2002/0078143 Al 



10 



Jun. 20, 2002 



privilege level by the protocol handler. If content comes 
from a privileged source, the protocol handler 112 assigns 
the highest privilege level. For example, all pages from the 
user interface definition files 104 which are stored in the 
ROM 126 of the wireless communication device 100 are 
assigned the highest privilege level. Formatted text mes- 
sages, whether received or created by the user, are assigned 
a lowest privilege level. Content that does not have an 
assigned privilege level is automatically given the lowest 
privilege level by the shell 106. For example, content from 
the World Wide Web (unless otherwise pre-assigned) is 
given the lowest privilege level. The privilege level of an 
item of content is stored with its URL in the URL history 
stack 108. 

[0163] Selected functions of the wireless communication 
device 100 arc configured to be privilege-sensitive by either 
the manufacturer of the wireless communication device 100 
or the service operator. When such a function is called it 
determines the privilege level of the page requesting the 
content from the page's URL in the URL history stack 108. 
If the privilege level of the requesting page is higher than the 
privilege level of the requested content, then the content is 
accessed. If the privilege level of the requesting page is 
lower than the privilege level of the requested content, then 
the function can either deny the access out of hand, or 
confirm the operation with the user. For example, if a lower 
privilege page requests to make a telephone call via the 
CallManager, the user is alerted to the actual number being 
dialed and must confirm the request before the phone is 
dialed. 

[0164] 6. The Content Handlers 

[0165] The following sections outline how the individual 
content handlers 114 implement the four functions in the 
API to each content handler 114. 

[0166] a) The HTMLp Content Handler 

[0167] (1) HTMLp API 

[0168] The HTMLp content handler 114c provides a fully 
HTML compliant parser, using the HTML 3.2 specification. 
This parser is activated as needed by the HTMLp content 
handler 114c during parsing of a page of content to create 
user interface entities for display of the screen display 136, 
and for storing respective data associated with such entities, 
such as labels, and associated data, including URLs to be 
fetched when the user interface entity is selected. 

[0169] As noted above, each content handler 114 provides 
an external interface of four functions, HTMLpOpen, HTM- 
LpClose, HTMLpActivate, and HTMLpProcessKey. HTM- 
LpOpen and HTMLpClose are described here. For ease of 
understanding, HTMLpActivate, and HTMLpProcessKey 
are described below, after a description of the new tags of 
HTMLp. 

[0170] (a) HTMLpOpen 

[0171] This function, called by the shell 106, gives control 
of the content area 214 of the screen display 136 to the 
HTMLp content handler 114c for displaying a page of 
content. As noted, the HTMLp content handler 114c receives 
from the shell 106 a stream of data to display, a handle to the 
content area 214, a display flag indicating whether the 
content data (the page) has been previously displayed, and 
a pointer to any extra data to be associated with the page. 

[0172] The function determines from the display flag 
whether the page has been previously displayed, and if so, 



whether any embedded object in the page was cached. In this 
case, the page is redisplayed and any embedded object has 
a Resto reState function called to reestablish its previous 
state. 

[0173] If the embedded objects for a page were not 
cached, or this is the first time the page is being displayed, 
the content stream for the page is passed to the underlying 
HTML parser to be interpreted as HTMLp code. The parser 
will create windows, and user interface entities as needed, 
and wrap text and update and assign softkeys 130 as 
necessary. When the page has been completely parsed, it is 
displayed to the user. In creating the user interface entities, 
the HTML parser establishes a table of associations between 
the user interface elements (including keys 132, softkeys 
130, menu items, and the like) and URLs (whether local or 
remote) bound to these entities. The association identifies 
each particular user interface entity, and a URL that is to be 
fetched if the entity is selected or otherwise activated by the 
user. These associations are used when subsequently pro- 
cessing key strokes received by the page by the HTMLp- 
ProcessKey function. A handle to the main window that 
holds all the other pieces of the page is set as a state block 
418 for the page via a call to ShellSetState. 

[0174] (b) HTMLpClose 

[0175] This function is called when the user closes the 
current page or switches to a different page. The shell 106 
passes in a flag indicating whether the page is to be removed 
from the URL history stack 108, or if it may remain on the 
URL history stack 108. If the page is not to be removed, and 
the page has not been marked as non-cacheable, then the 
main page is set not visible, effectively hiding it from the 
user, but maintaining it as an active page. 

[0176] If the page is non-cacheable or the page is to be 
removed from the URL history stack 108, the page window 
and its associated data structures are destroyed. A page is 
deemed non-cacheable when it refers to data outside itself 
that could potentially change while the page is not displayed. 
For example, if the page contains an <INC> ("include") tag 
or uses the configuration mechanisms described below to 
display a configuration setting, it is considered non-cache- 
able. The use of the conditional <IF> tag, and the <TEM- 
PLAXE> tag may or may not cause a page to be non- 
cacheable, depending on whether the DYNAMIC attribute 
for these tags is set, and whether a % [url] escape is 
encountered inside a <TEMPLATE><yTEMPLATE> block. 
These features are further explained below. 

[0177] (2) Extensions to HTML: HTMLp 

[0178] The present invention provides an MMI 102 that is 
fully HTML compatible. However, in addition to merely 
displaying content, it is desirable to provide a set of HTML 
extensions for further refining the user interface of a wireless 
communication device 100, making it more functional for 
telecommunication functions and the small screen display 
136, and allowing the wireless communication device to be 
easily and quickly customized by both the device manufac- 
turer and the service operator. 

[0179] The extensions which make up HTMLp are as 
follows: 

[0180] (a) A. User Interface Extensions 

[0181] In this section, the extensions of HTMLp which 
enrich the user interface are described. These various tags 
are decoded by the HTMLp content handler 114c when it 
receives a page of content from the shell 106. 
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(i) Binding Keys to Functions: <KEY> Tag 

[0182] A typical wireless communication device 100 pos- 
sesses one to three softkeys 130, the standard number keys 
134, and a number of special -purpose keys 132. A new 
extension of HTMLp allows any key of the keypad 128 to 
be bound by an HTML page using the <KEY> tag. The 
syntax is: 

[0183] <KEY KEY-key LABEL-string ACTION- 
url|POP|DONE|CLEAR|MEW|GO|NONE> 

[0184] The value of the KEY attribute is one of the 
following: 



[0187] When the HTMLp content handler 114c loads a 
page with the <KEY> tag, it creates a key binding table that 
stores the association between the key, label (if any) and 
action. 

[0188] The string bound to the ACTION attribute is pro- 
cessed by the HTMLpActivate function, as follows. 

(ii) HTMLpActivate 

[0189] The HTMLpActivate function is used to determine 
the appropriate response to the string that is bound to a user 
interface entity, such as a key, softkey, menu item, hyperlink, 



1, . . . m Specifics a softkey to be bound . Keys are numbered from left to right, 

or from top to bottom (depending on where they arc on the phone). 
Typically (m<=3), but this may be varied per device. 

send Specifies the "Send" or "Tali" key. 

back Specifies the "Back" key. Not all devices have this key. A page must 

be privileged to bind this key. 

Specifies one of the dialing keys, where n is the label on the key (0-9, 
*, or #). To bind all dialing keys to the same action, specify #x. 

end Specifies the "End" key. A page must be privileged to bind this key. 

mode Specifies the "Mode" or "ABC* key. 

clear Specifies the "Clear" or "Del" key. 

up Specifies the up-arrow key or down action. 

down Specifies the down-arrow key or down action. 

left Specifies the left-arrow key. 

right Specifies the right-arrow key. 

select Specifies the select key or action. 

power Specifies the power key. A page must be privileged to bind this key. 

default Specifies an action for any key for which no other action has been 

specified, with the exception of the back, end, and power keys, for 
which actions must always be explicitly specified, if any other than the 
standard actions are to be taken. 



[0185] If the key is a softkey 130, the value of the LABEL 
attribute is the string that appears in the on-screen label for 
the key. If the string is too long to fit in the space allotted, 
it is truncated. The LABEL attribute is valid only for 
softkeys 130. 

[0186] The value of the ACTION attribute specifies what 
should happen when the bound key is pressed. The possible 
values are: 



or the like. The input is a string from the shell 106, and more 
particularly, a string that is bound to the ACTION attribute 
of a KEY or KEYMENU tag, or the HREF attribute of an A 
tag. The new HTMLp tags generally allow any key or menu 
item of the wireless communication device 100 to be asso- 
ciated with a specific action or URL, 

[0190] Referring to FIGS. 6a-6b, there is shown a flow- 
chart of one embodiment of the HTMLpActivate function. 



URL Specifies a URL to be fetched, or some other command for an 

embedded object in the page. The URL is passed to the HTMLp 
content handler's HI MLp Activate function for processing. 

POP Requests that the previous page be displayed. 

DONE Requests that the page before the most-recent <TOP> page be 

displayed. 

CLEAR Requests that all pages be cleared from the URL history stack 108 and 

the main screen be displayed. 
MENU Specifies that the softkey 130 should bring up a menu. The items in the 

menu are specified by <KEYMENU> tags in the <HEAD> section. 

This is valid only for softkeys 130. 
GO Asks that the currently selected link be fetched. This is valid only for 

pages with the <LINKMENU> attribute. 
NONE Asks that no action be taken when the key is pressed. This allows the 

default action for the key to be overridden. 
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The HTMLp content handler 114c maintains a list of embed- 
ded objects in the current page. If there is an embedded 
object in the page (602), the function passes the string to the 
embedded object for processing 604. The embedded object 
returns a Boolean indicating whether the string was pro- 
cessed, and that no further processing of the string is 
necessary. If the string was processed by the embedded 
object (606), then the function returns 608 control to the 
shell 106. The processing 604 of a string to an embedded 
object is further described below. 

[0191] If the string was not processed, the HTMLpActi- 
vate function proceeds to process 610 the string according to 
its value as an ACTION attribute. 

[0192] If the string is "POP," (612) then the shell's 
ShellGoBack(POP) function is called 614. This function 
pops the top URL of the URL history stack 108, and cause 
the previous URL to be loaded. 

[0193] Similarly, if the string is "DONE," (616) the 
ShellGoBack(DONE) function is called 618, which is simi- 
lar, but displays the page before the most recent <TOP> lag; 
the <TOP> tag identifies the first part of a multi-part form, 
as further described below. 

[0194] The HTMLp content handler 114c maintains a 
pointer to a current object in the page, which can be an input 
field in a form or a hyperlink. This current object is where 
the input focus is located. 

[0195] If the string is "GO/' (620) and the current object 
is not a hyperlink (622), then nothing happens. If the current 
object is a hyperlink, the content handler 114 gets 624 the 
URL string associated with the hyperlink, and passes that 
URL string to ShellGetURL, which then fetches the actual 
content. 

[0196] If the string is "CLEAR," (626) then the ShellGo- 
Back(CLEAR) of the shell 106 is called 628. This function 
clears the URL history stack 108 and causes a default main 
page to be displayed. 

[0197] If the string has the form "resetformid (630) then 
the function returns 632 the input elements of form num- 
berformid to their original state. This action is bound to any 
softkey 130 or softkey menu for an <INPUT TYPE«reset> 
gadget. 

[0198] If the string has the form "submitformid,label/' 
(634) then the function submits 636 form number formid 
according to the METHOD and ACTION attributes of the 
FORM tag that denned form numberformid. If present, label 
indicates which <INPUT TYPE=submit> gadget the user 
activated, so its name-value pair can be submitted along with 
the values from the rest of the gadgets in the form. 

[0199] If the string is "SELECT", (638) then the function 
activates 640 the user interface gadget the user has selected, 
according to the gadget type as follows: 



<INPUT TYPE=radio> Selects that radio button and uoselecU other 
radio buttons with the same name. 

< INPUT TYPE=checkbox> Checks or unchecks the checkbox. 

<SELECT> If the options are displayed, it chooses the 

option the user has selected. If the SELECT 
list is a pop- down list, the pop- down is 
closed. 

hyperlink Follows the link. 



[0200] If the string is "NONE" (642), then no action is 
taken. 

[0201] After all these conditionals are passed, if the string 
is any other value (644), such as a URL, then it is passed 646 
to ShellGetURL to be processed. If the URL has no argu- 
ments (there is no *V in it), any parameters that were passed 
to this page as extra data are also passed in the call to 
ShellGetURL. 

[0202] An example of the HTMLpActivate function and 
its particular benefits for embedded objects is further 
described below. 

[0203] An example of processing by the Activate function 
using the <KEY> tag is as follows. Assume that a page 
contains the following KEY tag: 

[0204] <KEY KEY="send" ACTION=phone:dial> 

[0205] When this page is loaded, the HTMLp content 
handler 114c stores the association between the Send key 
and the URL "phone: dial" in its key binding table. This 
stored data will be used to activate the telephone dialing 
function of the telephone protocol handler 112g when the 
user presses the Send key. The HTMLp content handler 114c 
is the current content handler 114. 

[0206] Assume that at some later point the user presses the 
Send key. The portability layer 118 calls the shell's Shell- 
ProcessKey function indicating that a key has been pressed, 
and passes in a key number for the Send key, and a flag 
indicating that it has been pressed. As noted above, the shell 
106 maintains the keystroke target list. The ShellProcessKey 
sends the received key to the first target on the stack. If this 
target does not have a purpose for the key, then the target 
calls the Previouslnput function of the shell 106, passing the 
Send key index. The shell 106 finds the next item on its 
keystroke target list. This process repeats until the key is 
passed to the HTMLp content handler 114c. This happens 
when the shell 106 calls the ProcessKey function of the 
current content handler 114, since the URL at the top of the 
URL history stack 108 contains the pointer 406 to the 
HTMLp content handler 114c. 

[0207] The shell 106 then calls the HTMLpProcessKey- 
("Send"). This function looks at the key binding table, which 
includes the association between the Send key and the URL 
"phonerdial " The HTMLp content handler 114c calls Shel- 
LActivate(phone:dial), which calls the HTMLp content han- 
dler's 114c HTMLpActivate function. 

[0208] Here, it is assumed that there is no embedded 
object in the page. The function then tests the input string 
against the various other actions, such as POP, DONE, GO, 
CLEAR, and NONE. Since the string "phone:diar does not 
match any of these, the HTMLpActivate function calls the 
shell's ShellGetURL(phone:dial) function. 

[0209] The shell 106 processes this function, as shown in 
the flowchart of FIG. 5. Continuing the example, the shell 
determines that the URL is for the telephone protocol 
handler 112& and passes the "dial" portion to it for pro- 
cessing. This protocol handler U2g returns a content stream 
of type "CallManager" (destined for the call manager con- 
tent handler 114£) that contains the number to be dialed. The 
shell 106 closes the HTMLp content handler 114c, but does 
not remove the URL from the URL history stack 108. The 
shell 106 places the URL "phone:diaT on the top of the URL 
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history stack 108. The shell 106 gets from the content stream 
returned by the telephone protocol handler 112g the string 
name of the content handler 114 to handle the stream. The 
shell 106 looks up the string in its table, and updates the 
CONTENT field of the top entry of the URL history stack 
108. Finally, the shell 106 invokes the Open function of the 
new current content handler 114, passing in the content 
stream data. In the Open routine of the call manager content 
handler 114fc, it retrieves the phone number from the stream 
and invokes the necessary function in the telephone control 
module 120 to establish the phone call. 

(iii) Building Menus 

[0210] If a softkey 130 is bound to a menu using the 
<KEY> tag, and ACTION="menu", then the entries for the 
menu are specified using a <KEYMENU> tag in the HEAD 
section of the page. The <KEYMENU> tag has the follow- 
ing syntax: 

[0211] <KEYMENU KEY-n LABEL-string 
ACTION=url|POP|DONE|CLEAR|GO> 

[0212] Entries are displayed in the menu in the order in 
which they are encountered. However, menu entries do not 
all have to be together in the header. 

[0213] The value of the KEY attribute specifies to which 
menu the entry should be added. This is the same value as 
given for the <KEY> tag that specified a menu should exist. 

[0214] The value of the LABEL attribute is the string that 
appears in the menu entry. The menu will be as wide as 
necessary to hold all the entries. However, the label will be 
truncated if it is wider than the screen. 

[0215] The value of the ACTION attribute specifies what 
should happen when the entry is selected. The possible 
values are: 



URL Specifics a URL to be fetched, or some other command for an 

embedded object in the page. 
POP Requests that the previous page be displayed. 

DONE Requests that the page before the most- recent <TDP> page be 

displayed 

CLEAR Requests that all pages be popped from the URL stack 

and the main screen be displayed. 
GO Requests that the currently selected link be fetched. This is 

valid only for pages with the <LINKMENU> attribute. 



[0216] These ACTION attributes are processed in the 
same manner as the attributes of the <KEY> tag in the 
HTMLpActivate function, as described above. 

[0217] FIG. 7 illustrates example of the HTMLp source 
code for page with a key menu defined, and the screen 
display 136 when the menu is selected to be displayed. The 
HTMLp code is shown on the left, and the resulting page on 
the right. Line 4 defines a menu for the first softkey 
(KEY^l) Note that when the menu is open, the softkey label 
216 for the menu changes to "Select," indicating that if the 
user presses the softkey 130 again, the selected entry will be 
activated; this label 216 may change to instead close the 
menu, leaving the Send key to activate the selection. Lines 
5-7 define the menu items for this menu, each of which has 
its ACTION attribute specifying one of the user interface 
definition files 104 for the appropriate page to display to 



retrieve messages, recent calls, or phone settings. Selecting 
one of the entries in the menu, either by pressing the softkey 
marked "Select" or pressing the numbered key matching the 
icon to the left of the entry, causes the ACTION specified in 
the KEYMENU to be executed. In this example, the appro- 
priate HTMLp user interface definition file 104 is fetched 
from ROM. 

(iv) Delayed Help 

[0218] Many user interfaces for computers provide some 
form of online context-specific help text. Conventionally, 
these help screens are displayed in their own window 
overlaying the portion of the user interface where the user is 
expected to enter data. In addition, help screens are typically 
passive, and appear only in response to a direct action of the 
user to request help. However, in a wireless communication 
device with a very small screen display, overlaying a help 
screen over the content area would hinder the user. In 
addition, since the user may not know that help is available, 
passively waiting for the user to request help may be 
insufficient to assist some users. 

[0219] To assist users who might be uncertain of what to 
do next when viewing a page, and to provide such help 
without obscuring the content area 214 of a page where the 
user is expected to input data, the present invention enables 
help text to automatically scroll across the screen in place of 
the title 210 of a page after a certain amount of time has 
elapsed without a user input keystroke. More than one help 
text string may be specified, in which case the strings are 
displayed in succession, with a suitable interval between 
each one. The help text strings are displayed only once each, 
each time the page is viewed. 

[0220] To allow pages to specify one or more help strings 
a new <HELP> tag is specified in the <HEAD> section of 
the document. The syntax of the <HELP> tag is: 

[0221] <HELP>heIp string</HELP> 

[0222] where help string is the help text to be displayed. 

[0223] When a page containing the <HELP> tag is loaded, 
the HTMLp content handler 114c builds a structure, such as 
a table, that includes the help text strings. This table is 
passed to the shell 106, which stores the table for later use. 
The functionality of <HELP> tag is then handled primarily 
by the shell 106 during idle time processing. 

[0224] The shell 106 maintain a counter of the number of 
seconds since the last keystroke. The counter is normally 
cleared on each ShellProcessKey. The real time operating 
system 122 has a timer that runs in the background, and calls 
a routine in the shell 106 that increments the counter. If 
counter reaches a threshold number of seconds, the shell 106 
creates a scrolling banner object, and instructs it to display 
the first help text string in the table. The scrolling banner 
object internally determines when the help text string is fully 
scrolled off of the screen display 136, and notifies the shell 
106, which redisplays the title 210. A second threshold is set 
for displaying the next help string. The thresholds are 
predetermined by the shell 106 based on a desired length of 
time for displaying the help text strings. 

[0225] FIG. 8 shows an example of the HTMLp source for 
a page including two HELP tags, and the resulting sequence 
through which the screen display 136 passes when the page 
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is loaded. Lines 7-8 of the HTMLp code define the help text 
to be displayed. The second and third screen images show 
the first help text string being scrolled in place of the title. 

(v) Pages as Templates 

[0226] There are a number of extensions of HTML in the 
present invention that allow pages to be designed using a 
standard HTML editor, using arguments passed by C code to 
complete form entry fields, or specifying data to be fetched 
on the fly from the device to determine the initial slate of a 
form in a page. These extensions include templates, condi- 
tional HTML, configuration setting capabilities, and 
"included" HTML. 

[0227] Generally, the C code for an embedded object has 
parameters to be displayed, but it is desirable that the format 
of the display be defined in the HTML for the page. For 
example, a page displaying a form of data for an incoming 
call preferably displays a telephone number and its associ- 
ated name. Accordingly, the HTML page for displaying the 
incoming call should be able to take the parameters (tele- 
phone number and caller name) and format them as neces- 
sary. 

[0228] However, conventional HTML 3.2provides no 
mechanism to pass data directly into a page for this desired 
application, but rather at best allows the HTML for the page 
to be created on demand. The generation of HTML is both 
slow and compute-intensive, and the executable scripts for 
generating a page typically require more storage than the 
page being generated, thereby making it less efficient than 
storing the page itself. By allowing indirect passing of 
arguments, the present invention eliminates the need to 
generate HTML at run time. This enables the pages to be 
stored in the ROM 126, and requires less memory than the 
code for generating the HTML on demand. 

[0229] (a) Using Pages as Templates 

[0230] The first extension which enables data to be passed 
into a page is the <TEMPLATE> tag. The <TEMPLATE> 
tag may appear anywhere in page. It must be matched by a 
corresponding </TEMPLATE> tag at the appropriate place 
in the structure of the document. 

[0231] All text between the <TEMPLATE> and </TEM- 
PLATE> tags is examined for escapes of the form % (url), 
% [url] or %<url>. This includes text within tags, even 
within quoted attribute values. When such an escape is seen, 
the data for the URL are fetched and, if they are plain text 
or HTML, they are inserted into the HTML document in 
place of the escape exactly as if they had been there all 
along. To include a % character in the text between <TEM- 
PLATE> and </TEMPLATE>, it must be preceded by 
another %, as in "%%". 

[0232] The form %<url> causes the text returned as the 
data for url to be encoded for use as an argument for another 
URL. URL arguments have a restricted character set, with 
anything outside that character set being encoded as % 
followed by two hexadecimal digits. 

[0233] The distinction between % (url) and % [url] lies in 
the caching behavior of the HTMLp content handler 114c. 
Normally, the data for a page are parsed and the information 
needed to render the page is saved so long as the URL 
remains on the URL history stack 108. This allows for quick 



redisplay of a page that has already been fetched. If, how- 
ever, a % [url] escape is seen in a template section, it 
indicates that the data for the URL are dynamic enough to 
warrant the repassing the page when it needs to be redis- 
played, to catch any changes in the URL data since the user 
last saw the page, 

[0234] FIG. 9 illustrates an example of the TEMPLATE 
tag. In this example, the text between the <TEMPLATE> 
tags on lines 19-25 defines the template text; the escape on 
line 20 results in the URL "extra: name" being fetched, 
which replaces the text with whatever data is stored under 
the variable "name". The screen display shows this as the 
text "Adam M" 

[0235] The HTML 4.0 specification provides for the use of 
embedded objects in pages. Generally, an embedded object 
is an item of code positioned at a location on the page that 
is responsible for constructing and displaying its own con- 
tent. An embedded object is specified in the URL for the 
OBJECT tag, located in the desired position in the HTML 
source. Normally, the URL specifies a code entity such as an 
ActiveX control, a Java applet, C code, and the like. In the 
HTML 4.0 specification, the URL is merely passed to a 
server which return the desired entity. However, in HTML 
4.0 once a page with an embedded object is loaded, no 
further processing or passing of arguments to the embedded 
object can occur. In particular, when a user selects a hyper- 
link (a user interface gadget associated with a URL) on a 
page containing the embedded object, the embedded object 
does not have any opportunity to process the URL, and 
instead, the URL is merely followed to the linked page. 

[0236] However, the present invention extends the func- 
tionality of embedded objects by providing URL associated 
with a hyperlink or user interface gadget first to embedded 
objects for processing. This lets an embedded object respond 
directly to arguments provided in HTML forms, without 
having to have the server update the page. The implemen- 
tation of this embedded object functionality is provided in 
the HTMLpActivate function of the HTMLp content handler 
114c, as described above with respect to FIG. 6. 

[0237] As described, when the HTMLp content handler 
114c processes a string that is a URL, if there is an 
embedded object in the page, the HTMLp content handler 
114c passes the URL to the embedded object. In accordance 
with the present invention, an embedded object does one of 
three actions in processing a URL: 

[0238] Process the URL as a command; 

[0239] Look for escape sequences in the URL and 
substitute for those sequences information from the 
data the user selected, before passing the URL to the 
shell 106 to be fetched; or 

[0240] Return the URL to the HTMLp content han- 
dler 114c without processing, to be processed 
according to the remainder of HTMLpActivate. 

[0241] As an example of the second type of processing, an 
instance of the phone book embedded object in an HTMLp 
page may look for escape sequences such as "@n" or "@" 
to replace with the name or record ID of the phone book 
record the user has selected. The phone book object includes 
an edit method that can edit either the name of a record, or 
any of the fields. Passing the URL "phone :edit?Name-@n" 
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to the phone book object will begin the process of adding 
another number to the selected phone book record by 
entering the phone book entry creation process with the 
name already set from the selected phone book record;, 
passing the URL "phone: edit? id=@i" to the phone book 
object will edit all the fields of the record. 

[0242] The advantage of this extended functionality is that 
instead of having pages hardcoded in C, they can have those 
elements that require the data access and dynamic behavior 
of C be coded in C, while the specification of functions the 
user can perform is done in HTML. This is not possible in 
HTML 4.0 because the only way for an embedded object to 
interact with the user is by putting up its own user interface, 
which again will be hardcoded in the language in which the 
embedded object is implemented, and thus not easily modi- 
fied or branded by the service operator. 

[0243] FIGS. 10 and 11 provide two examples of possible 
phone book pages, and illustrate the flexibility embedded 
objects can provide with the extended processing of the 
present invention. 

[0244] In FIG. 10, the user can create a new entry, or 
modify one of the fields of an existing phone book entry to 
change its speed dial key, ring tone, or number. Line 5 
defines a key menu, which is shown displayed, activated by 
the user pressing the first softkey 130. The menu entries 
(lines 6-12) are bound to URLs that have escape placehold- 
ers for data from the current selection. In particular, line 6 
defines the ACTION for the menu item to be a URL for the 
embedded phone book object that will change to the first 
page of the phone book entry creation process with the name 
already specified to be that of the current selection in the 
embedded phone book object. Generally, other URLs in the 
present invention can be activated using pieces of the 
selected phone book record to fill in their arguments; any of 
these URLs can be bound to menu entries, softkeys, or other 
keys on the keypad. The specific escape sequences are 
described below, with respect to the phone: list URL of the 
phone protocol. 

[0245] In FIG. 11, the user can create a new entry, or go 
to a separate page to display all the parameters for a 
particular entry, and change them if she wishes (this is done 
via a separate screen, pbedil.html; the i @' escapes in the 
editurl argument to the phone: list embedded object extract 
all the relevant pieces of the entry for passing to pbedit.h- 
tml). In addition, the a graphical title bar is used here, along 
with a tiled background of the wireless communication 
device manufacturer's logo as a border. The object to embed 
is specified in line 10 with a URL to the phone list object. 

[0246] When the HTMLp content handler 114c encounters 
an <OBJECT> tag, it requests the shell 106 to fetch the data 
associated with the URL given as the CODE attribute to the 
OBJECT tag. The shell 106 returns this data as a content 
stream, which must be of type "Object". In the stream is a 
structure that contains: 

[0247] A pointer to the object (a window to be made 
a child of the HTMLp page window) 

[0248] A pointer to a function HTMLpActivate can 
call with the string it has been given. 

[0249] A pointer to a function that will fetch the 
current state of the object. This is called by HTM- 
Lp Close. 



[0250] A pointer to a function that accepts the state 
that was fetched and restores the object to that state. 
This is called by HTMLpOpen when it is told the 
page has been displayed before. 

[0251] Apointer to a function that returns the "value" 
of the object as a string. This is called when the 
object is part of a form that is being submitted. 

[0252] A pointer to a function that accepts the 
"value" to which the object should set itself. The 
value is a string. The function is called when the 
object is part of a form and extra data that have the 
same name as the object (as given by the NAME 
attribute to the OBJECT tag) were passed. 

[0253] (b) Accessing Device Settings 

[0254] The various configurable parameters of the wire- 
less communication device 100 are accessible via the config 
protocol, further described below. It is desirable to provide 
pages that can adjust these settings using form gadgets to 
specify the possible values for each setting. However, to do 
this, it must be possible to set the initial state of these form 
gadgets to match the current value of the setting they're 
supposed to affect. 

[0255] The form gadgets most preferably used to set the 
value of a device setting are the radio button, the checkbox, 
and the scrolling list. The radio button and checkbox are 
both accessed via the INPUT tag, with a TYPE attribute of 
either RADIO or CHECKBOX. For these input elements, it 
is possible in HTML 3.2 to specify a selection attribution 
which defines whether the input element is selected on the 
form. The selection attributes include CHECKED and 
SELECTED. The CHECKED attribute indicates that a radio 
button or checkbox is to be initially selected. Similarly, a 
scrolling list is specified by a <SELECT> tag, with 
<OPTION> tags inside it, any of which may have the 
SELECTED attribute to indicate that that option of the 
selection list should be initially selected. 

[0256] Normally these attributes are Boolean; if the 
CHECKED or SELECTED attributes exist in the source, the 
radio button, checkbox, or option is selected, while if they 
do not, it is not selected. In the present invention, however, 
these attributes have been extended to accept a value. The 
value takes the form of an expression, which, if it evaluates 
true, causes the item to be selected initially. 

[0257] The expression fetches data from a URL and either 
treats it as a Boolean value, to be checked for truth or 
falseness, or compares it to a string for equality or inequality. 

[0258] The syntax is: 

[0259] AITRIBUTE=[!]url 
[0260] or 

[0261] ATTRIBUTE-url[!]-string 

[0262] ATTRIBUTE is either CHECKED or SELECTED. 
The URL here is to a config protocol, and takes the form 
"config:setting" where setting is the particular setting of 
interest which the config protocol handler 1126 will access. 

[0263] The first syntax form treats the fetched URL data as 
a Boolean value, converting the text to an integer and seeing 
if it is 0 or non-zero. If the leading "!" is present and the 
value is 0, the item is selected, while if the leading is 
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absent and the value is non-zero, the item is selected. If the 
url itself contains an equal sign, it must be enclosed in 
parentheses. 

[0264] The second syntax form performs a string com- 
parison between the string and the data retrieved for the 
URL. If "!=" is given, the item is selected if the strings are 
not equal, while if just ■ is given, the item is selected if the 
strings are equal. 

[0265] If the data returned by the URL is neither plain text 
nor HTML, the expression always evaluates false and the 
item remains unchecked. 

[0266] FIG. 12 provides an example of the use of this 
extension, showing both the HTMLp source, and the result- 
ing page. Lines 9-14 specify the various configuration 
settings, showing the CHECKED attribute being set by an 
expression which is a URL to the config protocol hander. 
The illustrated page shows the resulting user interface for 
configuring these settings. In this example, the user will be 
presented with three radio buttons and a text input field. The 
user will be able to specify whether the backlight for the 
screen display 136 should be on only when the device is 
in-use, or when it's in-use or is plugged in, or not at all. In 
addition, the user can set the number of seconds without 
input after which the wireless communication device is 
consider to no longer be in use. These settings may be stored 
in the "backlight" and "backlight delay" settings, respec- 
tively. When the screen first appears, the radio button that 
corresponds to the current setting will be checked, and the 
text input field will contain the current delay. Generally, 
when an <INPUT> tag with this extended selection attribute 
is loaded, the HTMLp content handler 114c passes the URL 
to the shell 106 to be fetched. The HTMLp content handler 
114c evaluates the fetched data according to its syntax form, 
as described above, and establishes the value of the selection 
attribute according to the evaluation of the URL data. 
"Including" HTML 

[0267] "Including " is an extension to HTML that allows 
blocks of HTML or HTMLp code to be referenced in a page. 
Any included HTML is recursively resolved, so that 
included HTML may itself include other HTML. At present, 
the HTML 4.0 provides no mechanism to include blocks of 
HTML from one page into another. A benefit of included 
HTML is that common HTML components, such a page 
headers or footers, navigation toolbars, and the like, which 
are desired to appear in a number of pages, may be easily 
incorporated by a single reference to the included pages. 

[0268] The present invention provides a mechanism for 
including HTML (which also includes plain text) from any 
source, by giving its URL. This is used primarily to display 
device settings via template pages, but can also be used to 
reduce content size by placing elements common to multiple 
pages in a separate part of the content archive and including 
it in the other pages. The mechanism is provided by the 
<1NC> tag, which has the following syntax: 

[0269] <INC SROurl DYNAMIC> 

[0270] The SRC (source) attribute must be present, and 
specifies the URL whose data are to be included in the 
document at that point. When the <INC> tag is resolved by 
the HTMLp content handler 114c, the data associated with 
the URL is fetched inserted at the location of the <INO tag. 

[0271] An <INC> tag may be used anywhere in a page, 
except from within another tag. For example, "<AHREF= 
<INC SRC-file :commonurl.txt» J ' is not allowed. 



[0272] FIG. 13 illustrates an example of the <INC> tag. In 
this example, the first page infor.html has an <INC> tag on 
line 2 referencing the second file bbody.html, which itself 
has an <INC> tag on line 8 referencing a third file stdl- 
ogo.html. When the first page is loaded, the HTMLp content 
handler 114c fully resolves all <INC> tags, and produces the 
resulting page, as shown. File info .html has an <INC> tag on 
line 13 which references the file endbody.html, and this latter 
file includes the </BODY> tag properly closing the 
<BODY> tag that appeared in a completely different file, 
bbody.html. 

[0273] Generally, when parsing a page, as the HTMLp 
content handler 11 4e identifies an <INC> tag, it fetches the 
reference URL and directly inserts the data from the file into 
the source of the present file, and resolves it as needed for 
displaying the page. 

[0274] If the DYNAMIC attribute is specified for the 
<INC> tag, it causes the page to be rebuilt when the user 
returns to it, rather than using display instructions that were 
cached when the page was temporarily closed. In general, 
the DYNAMIC attribute indicates that the url used as the 
SRC refers to data that may change while the page is 
temporarily closed, so it must be reread and the page rebuilt 
to accommodate any such change. 

[0275] (d) Conditional HTML 

[0276] The display of pieces of a template HTMLp page 
can be controlled by parameters passed with the URL for the 
template page, either directly as arguments following a in 
a URL for the file protocol 112d (arguments specified in a 
URL for the file protocol H2d are available as values within 
the file using the extra :protocol), as form data from a 
METHOD-NEXT form in the referring URL, or as param- 
eters from C code in the present invention. 

[0277] Conventional HTML does not allow for condi- 
tional expressions to be encoded directly in the HTML 
source of a page to control which elements of the page are 
displayed. The present invention overcomes this deficiency 
with the new <IF> tag. The <IF> tag allows for testing of 
expressions, such parameters or device settings, to control 
the display of a page. The syntax is as follows: 



<IF TEST=expression DYNAMIC>html<ELSE 
TEST=expiession>htmUELSE>html<yiF> 
The expression in the TEST attribute is 
evaluated exactly like that described for 
the CHECKED and SELECTED attributes, above. 
For example, consider the HTMLp source: 
<IF TEST-extra:conf> 

<KEY KEY-1 LABEL-Conference 
ACTIO N-p hone :co n ference> 
<ELSE> 

<KEY KEY-1 LABEL-Tick Up" ACTION-phone:answer> 
</IF> 

<KEY KEY-send ACTION=phone:answer> 

<IF TEST=config:anykey> 

<KEY KEY-dcfault ACTION=phonc:answer> 
<KEY KEY=back AOTON=phone:answcr> 

<ELSE> 

<KEY KEY-default ACTION=nonc> 
<KEY KEY«back ACTtON=phone:ignoTe> 
</lF> 



[0278] In the first <IF> tag, TEST is evaluated with respect 
to extra data "conf 1 being passed into the page by the C code 
that loaded the page. This data is stored in a variable 
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available to the HTMLp content handler 114c. When the 
page is loaded, if "conf ' evaluates to TRUE, then the first 
softkey 130 (KEY=1) is labeled "Conference" and is bound 
in the key binding table to the URL "phone conference", to 
allow the user to activate the conference feature of the 
telephone. If "conf ' evaluates to FALSE, then the softkey is 
labeled "Pick Up" instead and the key is bound to a different 
URL. 

[0279] In the second <IF> tag, the tested data is a con- 
figuration setting of the wireless communication device, 
accessed by the "config:anykey" URL. Depending on the 
device configuration for this setting, either all keys, includ- 
ing the Back key, will be bound to the "phone: answer" 
function, or all keys but the Back key (and any other key that 
has a specific binding) will do nothing, while the Back key 
will be bound to the "phone:ignore" function. 

[0280] The <IF> tag has a DYNAMIC attribute that tells 
the parser that the URL it uses generates dynamic data and 
the page should be reparsed, similar to the % [url] form used 
in template mode to signal that url refers to data dynamic 
enough to require the page to be rebuilt when it is again 
made visible. 

(vi) Phone Number Entry Field 

[0281] HTML 4.0 is designed as a general purpose lan- 
guage, and does not include any features that make it 
particularly adapted for use in a wireless communication 
device, particularly one capable of making telephone calls, 
and storing telephone numbers and associated names. 

[0282] To make HTML more adapted for such a wireless 
communication device 100, the present invention specifies 
"phonenum" and "phonename" as new values for the TYPE 
attribute of the <INPUT> tag. Generally, <INPUT> tag 
allows specification of a data input type, such as a checkbox, 
radio button, text, or image. 

[0283] The new input type of the present invention allows 
the user to enter a phone number or a person's name. As the 
user types, the input field uses the input data to look up a 
matching record in a phone book data structure. Matching 
records are then displayed in a list below the input field in 
exactly the same format as is used in the phone book display. 
Once the matching records are displayed, the user is able to 
select an item in the list, and have that item be used to 
complete the form. 

[0284] More particularly, when the input type is "phone- 
num," the input digits are compared against all telephone 
numbers in the phone book; matching telephone are dis- 
played in a list. When the user selects one of the matching 
telephone numbers in the list, this causes the input field to 
be replaced by the full selected telephone number, with the 
portion that matched the input underlined. In matching, 
single digits (0-9) or double digits (00-99) are matched only 
against the speed dial list, and display matching speed dial 
numbers. 

[0285] When the input type is "phonename", the input 
characters are compared against the names in the phone 
book, and those entries that match are displayed, with the 
characters that matched drawn underlined. Matches in the 
first word of the name take precedence over matches in 
subsequent words and the list is sorted accordingly. When 



the user selects one of the matching names, this causes the 
input field to be replaced by the full matching name. 

[0286] FIG. 14 illustrates an example of the HTMLp 
source and the resulting page. Here, line 7 specifies the 
phone protocol for dialing a telephone number; the input 
type is "phonenum". The user has first typed in "2" which is 
matched against the speed dial list and displays a matching 
name. In the next image, the user has typed in "995" which 
is matched against the phone book list, and displays a single 
matching name. In the third image, the user has selected the 
name, which causes the entire telephone number that 
matches including prepending and remaining digits to be 
inserted into to the input field for use in dialing. 

[0287] (b) Multi-part Forms 

[0288] As mentioned earlier, in typical HTML pages des- 
tined for the desktop and its large screen, a conventional 
form will use many input fields. If such a form were 
displayed on the small screen display 136 of a typical 
wireless communication device 100, it would be very easy 
for the user to become lost in the form, because she loses the 
context of the form, most of which will be scrolled off the 
screen display 136 at any given time, or she cannot see much 
of the data being entered. FIG. 16 illustrates an example of 
a conventional HTML form which would be cumbersome to 
use on a screen display 136 of a wireless communication 
device 100. 

[0289] One solution is to break the single form into a 
series of forms that each gather one or two of the items 
required. In this case, however, conventional HTML 
requires the data from each form to be transmitted to the 
server as part of the URL that fetches the next form. The 
server then takes the data passed in the URL and returns a 
page that must be generated on-the-fly with the passed-in 
data from the previous forms included as "hidden" type 
input elements in the form in the returned page. In this 
manner, the data the user enters get sent up and back 
multiple times until the entire form has been filled in. This 
process is very bandwidth intensive, and time consuming, 
and costly. 

[0290] The other drawback to breaking a form into mul- 
tiple forms is what the user has to go through if she decides 
in the middle that she does not want to complete the form 
after all. In such a case, the user has to hit the "End" or 
"Back" key once for each of the subforms that have been 
filled in, since each is a separate page. If the user is in a 
hurry, she could easily overshoot and end up dropping out of 
a place she actually wanted to be in when canceling the 
form. 

[0291] FIGS. 17a 1, 17a.2, 17M and 176.2 illustrate a 
conventional multiple form method, as described above, 
where parameters received from a client computer in one 
HTML page are inserted by the server computer as HIDDEN 
type inputs in a next HTML page before being uploaded to 
the client computer. As seen in the figures, multiple pages 
have to be dynamically created to continually pass this data 
back and forth between the client and server. 

[0292] This protocol for sending data back and forth 
between a server and a client results from a fundamental 
assumption of standard HTML that each transaction 
between a client and server is stateless, and thus, no data 
from previous states may be implicitly relied on to complete 
a current state. 
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[0293] The present invention overcomes these deficiencies 
of HTML with a new "NEXT' method for forms, and a new 
<TOP> tag, which are designed to take advantage of the fact 
that clieat is fully able to save its own state and use this 
information in determining subsequent states. 

(i) The "NEXT* Form Method 

[0294] A form in an HTML page consists of one or more 
input elements for gathering data from the user. The data, 
each piece tagged with the name of the input element from 
which it came, is submitted to a server according to two 
parameters in the FORM tag: the METHOD and the 
ACTION. The ACTION is a URL to which the data are 
usually appended, while the METHOD is either GET or 
POST. GET is used to fetch another page based on the data, 
while POST is usually used to send data to finalize a 
transaction. 

[0295] To these two methods, the present invention adds a 
new NEXT method. Generally, the NEXT method allows a 
form to be specified in multiple parts, with each part 
including a subset of all of the input fields of the overall 
form, and the data for the entire form stored in an external 
data structure. 

[0296] The NEXT method has the following effects: 

[0297] 1. The method used on the ACTION URL is 
"GET" without any modification of the URL; the 
page is simply fetched from the server. GetURL is 
the function called for the protocol handler 112. 

[0298] 2. Any form in the fetched page begins with 
the name/value data-set active in the form on the 
current page. This includes any name/value data that 
was passed from a previous page. This replaces the 
use of "hidden" input fields, avoiding the bandwidth 
penalty of having to transfer the data up to the server 
and have it transfer the data and the page back again. 
Instead, the page can reside on the server without an 
associated CGI script, or it can reside on the device, 
having been downloaded with the other pages that 
make up the transaction when the user subscribed to 
the service. 

[0299] FIGS. 18a.l, 18a.2, 18a.3, 18&.1 and lSb2 illus- 
trate the HTMLp source and pages for a multi-part form that 
captures the same information as the illustrated conventional 
HTML pages, but presents in a significantly more useful and 
easy to use format for a screen display 136. The first three 
pages, "purchaseform .html ""addr.html," and "credit .htmr 
all use the NEXT method in the <FORM> tag to specify the 
next page to be loaded to obtain additional inputs. The last 
page "con firm. html/' uses a conventional ACTION value to 
specify the CGI script for processing all of the data accu- 
mulated on the multi-part form. In this manner, much lower 
degree of bandwidth is needed between the server and the 
client to obtain all of the inputs to the form and transmit 
them back to the server, since the client (the wireless 
communication device 100) maintains the state data of the 
previous input pages. This state data of the name, address, 
credit card number, and so forth is maintained in an internal 
data structure of the wireless communication device 100 in 
its memory 126, and thus need not be embedded in HIDDEN 
type input elements as in conventional HTML. This internal 
data structure is created as the first page is parsed by the 



HTMLp content handler 114c, and updated as each new 
page in the multi-page form is loaded. 

[0300] The <TOP> tag and "DONE" action used in the 
"confirm.html" page are explained in the following section. 

(ii) Complex Interactions 

[0301] Given that what would be a multi-element form in 
standard HTML displayed in a desktop browser can now be 
transformed into multiple pages in HTMLp, each of which 
contains a one- or two-element form (in order to fit on the 
screen display 136 comfortably), a user might easily find 
herself in the middle of providing data for each of the fields 
and decide she wishes to terminate the whole process. If all 
she can do is go back to the previous page, this could be a 
slow and tedious process to terminate the transaction. 

[0302] To make termination of a multi-page form easier, 
the present invention allows a page to be marked as the 
beginning of a complex interaction a user might want to exit 
completely. It does this by providing the <TOP> tag: 

[0303] <TOP> 

[0304] at the desired location of the "top" of the interac- 
tion. Such an interaction may be a multi-part form, or any 
other complex group of pages. 

[0305] To access the top of an interaction, a softkey 130 is 
defined using the <KEY> tag with an ACTION attribute of 
"DONE". When this softkey 130 is selected by the user, the 
user will return to the page that referred the user to the most 
recent page marked with <TOP>. This processing of the 
DONE value for ACTION takes place during the HTML- 
pActivate function, as described above. 

[0306] (c) Navigation 

[0307] The display of HTML on a conventional wireless 
communication device 100 is further hampered by the 
heavily-restricted keyboard and the absence of any pointing 
device. In a typical HTML environment, there is a scrollbar 
that can be clicked or dragged, a tab key to shift between 
fields in a form, and a mouse that can select hyperlinks 
included in the content should the user wish to follow them. 

[0308] In a wireless communication device 100 in which 
the present invention advantageously operates, however, 
there is only the up key, down key, and possibly one of the 
softkeys 130 that may be relied upon to provide navigational 
controls. To provide a rich set of navigational abilities, the 
present invention provides the following features to 
HTMLp. 

(i) Form Entries 

[0309] When a page contains form elements, the Up and 
Down arrows are overloaded to allow moving between the 
form fields in the following fashion: 

[0310] If the next (for the Down arrow) or previous 
(for the Up arrow) field in the form is visible, then it 
is made the active form field. This is denoted by a 
graphical selection indicator; a text input element 
will also get a blinking text cursor. 

[0311] If the next (or previous) field in the form is not 
visible on-screen, the screen is scrolled so that the 
next (or previous) line of the page is brought on- 
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screen. If the next (or previous) field is in the line that 
was brought on-screen, then it will be made the 
active form field. Otherwise, the current form field 
remains active. 

[0312] As the screen display is scrolled, the current form 
field, is continually updated without requiring the user to 
directly select the field. In this manner, the user can easily 
switch among fields merely by scrolling, while being able to 
predictably read explanatory text leading up to the next field 
to be filled in. 

[0313] In addition to this, if the first softkey 130 is not 
bound by the page to some other purpose, it will change its 
action in the key binding table as the current form field 
changes, as follows: 

TABLE 1 



SofUcey Navigation Defaults 



GADGET WITH FOCUS 


SOFTKEY 
LABEL 


ACTION 


Text field 


no label 




Scrolling List (single 


OK 


Selects and generates 


selectable) 




Submit 


Scrolling List 


Select 


Selects/de-selects item. 


(multi- selectable) 






Popdown (closed) 


Open 


Opens popdown 


Popdown (open) 


Select 


Closes popdown and makes 






selection 


Checkbox (selected) 


Clear 


De-selects 


Checkbox (unselected) 


Select 


Selects 


Radio button (unselected) 


Select 


Selects button 


Radio button (selected) 


no label 




Standard link 


Select 


Activates link 


Phone :Dial link 


Call 


Goes to Dial screen 






displaying the number (can 






also be activated with Send 






button). 



[0314] The various actio as defined in Table 1 provide for 
appropriate and dynamically variable behavior of the soft- 
key 130 depending on the type of user interface gadget that 
is the current form field. These actions are dynamically 
assigned as the user scrolls a page and changes the focus 
between gadgets, thereby changing the current form field. 
For example, if the current form field is a hyperlink, then the 
softkey is automatically assigned to the URL for the link, 
and selection of the softkey automatically fetches the hyper- 
link. If the form field is some type of selection device, such 
as a list, popdown, checkbox, or radio button, then the 
softkey will either select, deselect, or submit an item from 
the selection device, as appropriate. For example, if a 
scrolling list has an item preselected using the SELECTED 
attribute (with or without the expression evaluation feature 
of the present invention) then the softkey 130 is defined to 
deselect the item. 

[0315] This functionality for page navigation is imple- 
mented in the HTMLpProcessKey function. This function is 
called by the shell 106 when no other entity of the current 
page elects to receive an input keystroke. The input to the 
function is a key number indicating the key of keypad 128, 
and a Boolean indicating whether the key is pressed or 
released. Referring to FIG. 15 there is shown a flowchart of 
one embodiment of the HTMLpProcessKey function. 

[0316] If there is a URL associated with the key, then the 
ProcessKey function 606 invokes 1502 the GetURL func- 



tion of the shell 106, passing the associated URL. The shell 
106 will process this URL as illustrated in FIG. 5, to 
determine the appropriate protocol handler 112 and content 
handler 114 for handling the URL. 

[0317] The function determines 1502 from the key number 
whether or not the key has been bound to some action using 
the <KEY> tag, or the KEY attribute of the <A> or 
<INPUT> tags. If so, and the key is not a softkey 130 (which 
is handled by the shell 106), then that action is passed 1504 
to ShellActivate when the key is released. 

[03 18] Otherwise, only the Up and Down keys are handled 
specially (1506); all others are passed 1508 to ShellDefault- 
ProcessKey to receive their default handling. 

[0319] The behavior of the Up and Down keys depends on 
whether there are selectable user interface gadgets on the 
page. A selectable gadget is either a form input field (from 
the INPUT, SELECT, TEXTAREA or OBJECT tags), or a 
hyperlink (if the LINKMENU tag is present). If there are no 
selectable gadgets on the page (1509), then the function 
makes 1514 the next line in the given direction visible. 

[0320] If there are selectable gadgets on the page (1509), 
the reaction to an UP or DOWN key is as follows. If the next 
user interface gadget in the chosen direction is visible 
(1510), the function makes 1516 that gadget the current 
gadget. If the next user interface gadget is not visible, then 
the content area 214 is scrolled 1512 so that the next line in 
the given direction is visible. If this makes the next gadget 
visible 1513, it is made 1516 the current gadget. If no user 
interface gadgets are visible, then no gadget is current. 

(ii) Content-as-Menu 

[0321] Content that does not contain a form can roughly 
be grouped into two classes: 1) informational content that is 
meant to be read, and 2) menu content that allows the user 
to select something from a list, in order to get further 
information or perform some action. 

[0322] The scrolling and link-selection behavior needed 
by the user is different for each of these types of content. In 
informational content, the scrolling should allow the next 
piece of the text to be read (as that is the focus of the 
content), with any links being selected from a menu (the 
links are of secondary importance). For menu content, 
however, the importance is reversed: the text serves to 
explain the finks, but it is the links themselves the user needs 
to see. As such, a link should always be selected and any 
scrolling that occurs should occur in the context of getting 
to the next link. Conventional HTML does not distinguish 
between these types of content, and provides no mechanism 
for altering the navigational features of the computer dis- 
playing the content to accommodate their differences. 

[0323] To distinguish between these two types of content, 
and provide the desired navigational controls, the present 
invention provides a new <LINKMENU> tag. The <LINK- 
MENU> tag can be given in the header to indicate the 
content is a menu of choices. The syntax is as follows: 

[0324] <LINKMENU TARGET-name 
NOSCROLL> 

[0325] The TARGET attribute has a value that is matched 
against the NAME attribute for all links on the page. The 
link whose name value matches the TARGET value is the 
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link that is initially selected when the page is displayed. If 
the TARGET value takes the form of a URL (the first part of 
the value is alpha characters followed by a colon), the URL 
is fetched and the returned contents are compared against the 
NAME attributes for all links on the page. 

[0326] If the NOSCROLL attribute is present, it requests 
that the display not scroll to make the selected link visible. 

[0327] Specifying a <LINKMENU> has the following 
effects: First, links are not distinguished graphically (e.g. 
they are not underlined), as in conventional HTML. Second, 
the first link on the page is marked as selected (unless the 
TARGET attribute is given). Finally, the up and down keys 
set the current user interface gadget to the previous or next 
link that is visible, as described in the HTMLpProcessKey 
method. The next link is defined as the one below the current 
one and the shortest horizontal distance away; this allows 
columns of links to be handled gracefully and in an expected 
manner. If the previous or next link is not visible, the screen 
scrolls a single line in the appropriate direction. If the 
desired link is then visible, it is selected, otherwise the 
current link remains active, unless it is now not visible. 

[0328] If <LHSTKMENU> is not given in a page, the 
content is treated as follows. First, links are distinguished by 
underlining them. Second, If the last softkey is not bound to 
anything, all links in the page are gathered into a menu 
bound to that softkey. Finally, the up and down selectors 
scroll the page one text line at a time. 

[0329] This functionality of the <LINKMENU> tag is 
effected by the HTMLp content handler 114c when the 
handler parses the page and sets up the key binding table and 
menus. 

[0330] FIG. 19 illustrates an example of the second type 
of behavior, where <LINKMENU> is not specified. In this 
example, all of the links to other content including files, such 
as iguana.gif, and lizards/blue -tongued-iguana.html, or data- 
base data, <a href=map?city=adelaide label=map>, are auto- 
matically placed in a menu named "Links" that is bound to 
the second softkey 130. This menu is displayed, as in the 
second image, when the softkey 130 is pressed. 

[0331] FIG. 20 illustrates the first type of behavior, where 
<LINKMENU> is specified. Note that the links in the page, 
e.g., <A HREF=flights/ua909.html>UA 909</A>, are not 
underlined, as in conventional HTML. Rather, the Up and 
Down arrows will move and select these links in order. 

(iii) Binding a Link to a Key 

[0332] The present invention provides new attributes for 
the <A> tag. These attributes provide a compatible way to 
provide content for both a wireless communication device 
100 and a desktop computer, as a standard HTML browser 
will ignore the attributes. These attributes are the KEY and 
LABEL attributes: 

[0333] <A KEY-key LABEL-string HREF-url> 

[0334] If specified, the KEY attribute asks that the indi- 
cated key should follow the URL specified by this for the 
HREF. The "back" key may not be bound in this way. This 
attribute thus provides a means for binding a specific key to 
a specific URL. 

[0335] If specified, the LABEL string will be used in one 
of two ways: 



[0336] If a KEY is also provided and is a softkey 130, the 
string will be the label for the softkey 130 displayed on the 
screen display 136. 

[0337] If a KEY is not provided, the string will be the label 
used in the menu of links that is automatically built by 
HTMLp content handler 114c when the LINKMENU tag is 
not given. In the absence of a LABEL attribute, the text of 
the link will be used (as much of it as will fit). 

(iv) Binding Keys to Input Elements 

[0338] Conventional HTML provides for SUBMIT and 
RESET attributes for the <INPUT> tag. However, these 
attributes a hardcoded to either a return key, or a mouse click 
on a user interface gadget. 

[0339] The present invention extends the use of the SUB- 
MIT and RESET input elements by enabling them to also be 
bound to particular keys, using a KEY attribute for the 
<INPUT> tag that specifies the desired key to be bound. 

[0340] In a preferred embodiment, by default, SUBMIT 
elements are bound to a second softkey 130, and RESET 
elements are bound to the third softkey 130. If a device has 
only two softkeys 130, RESET elements are inaccessible. 
Given the simplicity of forms on these devices, however, 
this is not usually a problem. 

[0341] A form with multiple SUBMIT elements will have 
all of them placed in a menu on the second softkey 130, 
unless an explicit key binding is given. Multiple SUBMIT or 
RESET elements bound to the same key will be combined 
into a menu on that key. 

[0342] (d) Specialized Content 

[0343] The present invention also includes additional 
extensions to HTML to support specialized types of content 
or provide a way to map existing World-Wide Web practices 
to the smaller screen display 136 of the wireless communi- 
cation devices 100. 

(i) Dialing the phone 

[0344] Like other telephone type products, wireless com- 
munication devices 100 can access DTMF-based network 
services, or other systems that use DTMF tones to control 
functionality, such as voicemail systems, and the like. 
Accordingly, HTMLp includes a new tag that makes it very 
easy to generate DTMF tones when a page is fetched in 
order to easily interface with such systems. This is accom- 
plished using the new <DIAL> tag: <DIAL NAME-string 
ICON=mimber NOSCREENCHANGE>(n|n@t;)+</DIAL> 

[0345] n is a number or special dial code (like p for pause). 
@t; specifies a duration, in tenths of seconds, if it is present. 
The choice between generating DTMF tones and making a 
new call is made based on whether a call is currently active 
(not on hold): if a call is active, the DTMF tones are 
generated. 

[0346] The NAME and ICON attributes specify the party 
being called, to be used in the page that is displayed while 
the call is being placed, and in the follow-up page that allows 
the dialed number to easily be placed in the phone book. 
While the ICON attribute is also used in a call-connecting 
page, its primary purpose is in a call follow-up page that 
allows the user to store the dialed number in the phone book: 
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phone numbers are identified by their icon in the embedded 
phone book object and elsewhere, and the ICON attribute 
specifies the icon to use, if the user does not change it when 
actually entering the number. 

[0347] The NOSCREENCHANGE attribute indicates that 
the display should return to this page after the call is 
successful, rather than changing to be a standard call man- 
agement page, such as in FIG. 22. 

[0348] Any attempt by a non -privileged page to actually 
make a new call is confirmed with the user, to prevent 
malicious content from issuing unwanted phone calls. 

[0349] This tag allows for a user interface page to provide 
a graphical instruction sheet for existing DTMF-based com- 
mand trees. The user activates functions on the screen which 
then bring up a new page that generates the appropriate 
DTMF tones to execute the action the user requested, and 
that displays the operations available to the user in the new 
state. FIG. 25 illustrates an example of this type of use. The 
file entitled "Voice Box" is a user interface page for access- 
ing a voice mail system. The <DIAL> tag in line 2 includes 
the telephone number for the voice mail system, and a user 
password "4416722**. Lines 4-8 define the keys of the 
keypad 128 to activate various functions of the system. In 
the file entitled "Listen", the <DIAL> tag in line 2 first 
generates the DTMF tone corresponding to the number "5" 
which triggers the voice mail system to enter a playback 
mode. Lines 4-8 here assign respective number keys 134 to 
various actions, each of which is a URL to dial a specific 
number that generates further functions of the voice mail 
system. Thus, using the <DIAL> tag allows the user to 
navigate a voice response system's command tree in graphi- 
cal manner, while providing the correct underlying DTMF 
signals. 

[0350] The <DIAL> is provided by the HTMLp content 
handler 114c to the shell 106, which in turn provides it to the 
telephone protocol handler 112g for processing, and gen- 
eration of the DTMF tones corresponding the numbers 
provided in the URL. 

(ii) Advertising Content 

[0351] Existing World-Wide Web content is largely sup- 
ported by graphical advertising banners. The limited band- 
width and screen size of the screen display 136 on wireless 
communication devices 100 makes this sort of advertising 
problematic, however since conventional image-intensive 
advertising banners will not properly display on a wireless 
communication device 100. 

[0352] The present invention overcomes this limitation by 
providing an extension to the existing <MARQUEE> tag. 
This tag normally specifies text to be scrolled across the 
screen, but is limited to the <BODY> section of the page. 
Conventionally, if the <MARQUEE> tag is placed in the 
<HEAD> section, a conventional browser will ignore tag. 

[0353] In the present invention, HTMLp content handler 
114c allows the <MARQUEE> tag to be placed in the 
<HEAD> section of a document. When so used, the accom- 
panying advertising text in the <MARQUEE> tag alternates 
with the title of the page and any delayed help that has been 
specified with the <HELP> tag. This functionality is imple- 
mented by the HTMLp content handler 114c responding to 
a call from the shell 106, which is asked to notify the 



HTMLp content handler 114c every other time the shell 106 
would otherwise display delayed help. When notified, the 
HTMLp content handler 114c instructs the shell 106 to scroll 
the advertising text across the title area 210. 

[0354] In summary, the HTMLp content handler 114c and 
the HTMLp extensions provide numerous beneficial fea- 
tures and functions not present in conventional HTML. 

[0355] b) The Advertising Manager 

[0356] The advertising manager content handler H4a 
selects an advertisement to display at idle time, deletes old 
advertisements or those that have been responded to or run 
their requisite number of times. The advertisements are 
defined as HTML or HTMLp pages and stored in memory 
126 as part of the user interface definition files 104. Adver- 
tisements are typically downloaded to the wireless commu- 
nication device 100 by the operator on a scheduled basis. 
After the user responds to them, or they have been displayed 
a certain number of times, or if a more-important advertise- 
ment arrives, downloaded advertisements are automatically 
deleted. 

[0357] The advertising manager content handler 114a 
implements the basic content handler functions as follows: 

[0358] (1) AdvertOpen 

[0359] An advertisement page is never rerun, as the adver- 
tising manager content handler 114a marks the page as 
temporary, and thus does not store it on the URL history 
stack 108. This means that any other page that comes up 
(e.g. incoming call, battery low, or like) will replace the 
advertising page in the URL history stack 108. 

[0360] When AdvertOpen is called, it looks at the set of 
advertisement pages it has available and chooses one to 
display. It opens the file and passes the stream to the HTMLp 
content handler 114c to display. 

[0361] (2) AdvertClose 

[0362] This function checks the advertisement page it was 
displaying, and if it is marked for deletion (because it has 
been responded to or because it has been displayed the 
required number of times), it deletes the advertisement page. 

[0363] (3) AdvertActivate 

[0364] The string is passed to the HTMLp content handler 
114c to be processed in HTMLpActivate after the current 
advertisement is marked for deletion since the user has 
responded to it. 

[0365] (4) AdvertProcessKey 

[0366] Any key press that is not otherwise bound in the 
advertisement page causes the page to be closed and the key 
press to be reprocessed by the page that was active before 
the advertisement page appeared. 

[0367] c) The Call Manager 

[0368] The call manager content handler 1146 is used for 
two purposes: 

[0369] 1. To display the active calls 

[0370] 2. To display the connection progress for an 
outgoing call 
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[0371] There is only ever one page on the URL history 
stack 108 that currently uses the call manager content 
handler 114b, and that page is in one of these two modes. 
The call manager content handler 114b implements the basic 
content handler functions as follows: 

[0372] (1) CallManagerOpen 

[0373] If the page is being rerun, this function makes the 
window it created before to display the page visible again 
and redisplays its contents. 

[0374] If this is the first time the page is being opened, 
CallManagerOpen examines the stream of data for the URL 
to see if there is a phone number to be dialed. In the stream 
will be a string of the form: 

[0375] num-string&name-string&icon-n 

[0376] This tells the function the number to dial (with 
following DTMF tones, if any), the name to display for the 
number (if the number itself is not in the phone book), and 
the icon to display along with the name. 

[0377] If there is a number to dial, the call manager 
content handler 114b will enter dialing mode, using an 
interface provided by the telephone control module 120 and 
display a dialing page showing the progress in making the 
phone call. This page provides feedback as to which DTMF 
tones are being dialed, and will report errors should they 
arise. FIGS. 21a-e illustrate an example dialing page, show- 
ing the status of the connection as "connecting/'"line is 
busy," and so forth. In FIGS. 20c-e also show the entire 
phone number being dialed, with a moving indicator under 
the present digit which is being dialed. 

[0378] In the absence of a number to dial, the content 
handler 114ft CallManagerOpen function displays the list of 
active calls, along with interface to manipulate them, A 
simpler interface is presented if there is only one call active. 
FIGS. 21a-c illustrate these interfaces. FIG. 21a shows the 
interface for a single active call; FIG. 21b shows the 
interface for multiple active calls; FIG. 21c shows the same 
interface as FIG. 21b but with a softkey 130 menu that 
allows for selection of whether to conference or hold a call. 

[0379] (2) CallManagerClose 

[0380] If the page is being closed permanently, and is 
removed from the URL history stack 108, this will free up 
the resources it allocated to display the active calls. If there 
are still calls active, this function calls ShellAddldleHook so 
after a certain amount of time with no user input, the list of 
active calls will again be displayed. 

[0381] (3) CallManagerActivate 

[0382] This function looks for the following commands 
that are bound to the softkeys 130, depending on what 
actions are available for the selected call: 



Conference Joins the other (on-hold) call to the current call in 
a multi-party call. 

Split Removes the selected call from the multi-party call it is in. 

Hold Places the selected call or multi-party call on hold. 

Pick Up Activates an on-hold call or multi-party call. 
Back Closes the call manager screen. 

Stop Stops the current DTMF sequence and displays the list of 

active calls in place of the call-in-progress screen. 



[0383] (4) CailManagerProcessKey 

[0384] This function handles the Up and Down keys in the 
multiple -call case, moving the user selection from one call 
to the next. The call that is selected is made the active call 
and the old active call is put on hold. 

[0385] Number keys 134 generate DTMF tones if the 
active call is selected (in spite of the response to the Up and 
Down keys, which would seem to indicate that it is not 
possible to have the currently selected call not be active, it 
is possible for the selected call to be on-hold if the user just 
asked to put it on hold and has not changed the selection), 
else a dialer screen is brought up, and the digit is entered as 
the first of a number to call. 

[0386] The End key terminates the current call. If the call 
is part of a multi-party call, it is removed from the confer- 
ence before it is terminated. 

[0387] The Send key brings up the dialer screen, but does 
not affect the current call until the user hits Send to make the 
second call. 

[0388] d) The Main Content Handler 

[0389] The main content handler H4d serves largely as a 
front-end for the HTMLp content handler 114c to display the 
main page of the device. 

[0390] (1) MainOpen 

[0391] Resets the input mode to numeric and the shift state 
to unshifted, so when the user starts pressing keys, they start 
dialing a number. 

[0392] It then opens a stream to the main page, and passes 
the stream to the HTMLp content handler 114c to display. A 
sample main page is illustrated in FIG. 22. 

[0393] (2)MainClose 

[0394] Calls HTMLpClose with the same arguments. 
[0395] (3) MainActivate 

[0396] Calls HTMLpActivate with the same arguments. 
[0397] (4) MainProcessKey 

[0398] If the key is End and there are calls active, this 
function will bring up the active call screen, so the user does 
not have to wait for it to appear to be able to hang up. 

[0399] Any other key press is passed to HTMLpProcess- 
Key to be processed. 

[0400] 7. The Protocol Handlers 

[0401] In accordance with the present invention, the func- 
tionality of the wireless communication device 100 is 
accessed through a number of protocols and protocol han- 
dlers 112 that fetch or post data or execute a requested 
function in response to a URL identifying such data or 
function. 

[0402] In a preferred embodiment, there are three main 
protocols for interacting with the wireless communication 
device 100: phone, message, and config. A fourth protocol, 
the "extra" protocol, enables HTMLp template pages to be 
used for most of the user interface, as described with the 
<TEMPLATE> tag and other features. 
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[0403] For each protocol, the supported URLs are sepa- 
rated into those that return an object to be embedded in an 
HTML or HTMLp page, and those that display content or 
activate a function of the wireless communication device 
100. 

[0404] a) The phone Protocol 

[0405] This is the primary protocol for accessing the 
features of the device and the various embedded objects that 
are written in C, rather than HTML. It is decoded by the 
telephone protocol handler H2g. These embedded objects 
include the phone book object, recent call list object, and the 
like, as described above. Each embedded object has param- 
eters width and height. These parameters are specified in the 
URL for the embedded object, and define the pixel width and 
height for a window to be provided by the embedded object 
to display its output. 

[0406] Each embedded object also has a set of methods 
which it executes according to the URL specification. 

[0407] (1) Embedded Objects 

[0408] For each embedded object, there is described the 
parameters it accepts, as well as the methods that can be 
performed on it. These methods are strings that are bound to 
keys 128, hyperlinks, or softkey menu entries. 

[0409] phone :dialing?width-number&height= 
number&storekey=n,storelabel/editlabel 

[0410] Returns a stream containing an embedded object 
for dialing the phone. The object can look up entries in a 
stored phone book data structure by number or by name, and 
displays matches below its input field, as described above, 
with respect to the phonename and phonenum attributes of 
the <INPUT> tag. 

[0411] Parameters 

[0412] storekey Specifies which softkey 130 should 
be used to allow the user to edit an entry, if she has 
selected an entry in the match list, or to store the 
number or name that she has entered. The storelabel 
and editlabel values specified for the storekey param- 
eter specify the label to be given to the softkey when 
it is set to perform either of those two functions. 

[0413] Methods 



edit Requests that the number selected in the match list be edited. 

store Requests that what the user has typed be stored in the phone book 
by entering the new-phone book-entry sequence with the 
appropriate field filled in from what the user has typed. If 
the current text entry mode is numeric, the entered data are 
taken to be the phone number; if the current text entry mode 
is non-numeric, it is taken to be the name. 



[0414] Any action that contains an '@' character is also 
considered a method of this object. The @ escapes described 
for the phone:list object will also function here. 

[0415] phone :list?width=number&height=« 
number&editkey-n,label&service-string&data- 
string& showstatus 

[0416] Returns a stream containing the phone book 
embedded object to display records from the phone book 
data structure. 



[0417] Parameters 



edit key Specifies a softkey 130 whose label and action 

should be changed depending on what is selected 
(only phone numbers can be edited). 

service, data Specify strings to display in the status message 

area 212 when a service (URL) or data (stored content) 
entry is selected, while showstatus determines whether 
any status message 212 is displayed 

(for phone number entries, the phone number is displayed). 



[0418] Methods 



new [f the list is in search mode and an entry in the match list nas seen 
selected, a new-phone book-entry sequence, a sequence of user 
interface definition files 104 that collect the name, number, and 
forth, and store the result in the phone book, is entered using 
the name of the selected entry as the name for the new entry, 
[f no entry in the match list is selected, the new-phone book-entry 
sequence is entered with what the user has typed as initial data. 
The data are used for the phone number if the current text-entry 
mode is numeric, or for the name if the current text-entry 
mode is not numeric. 

edit A URL is generated to edit the current phone book entry, 
and the URL is fetched. 

delete The current phone book entry is deleted, after confirming 
the request with the user. 



[0419] Any URL that contains an @ character is also 
considered a method of this object, and is searched for the 
following escapes. If an escape is found, it is replaced by the 
relevant piece of data from the current selection. Once all 
escapes have been substituted for, the resulting URL is 
fetched. 

TABLE 2 



Escapes Values 

Escape 

@i The record ID of the selected entry 

@o The offect of the selected phone number in the entry (0-7) 

@n The name in the selected entry 

@N The selected phone number (generates an error if the selected 

icon is not a phone number) 
@I The icon of the selected phone number (generates an error if the 

selected icon is not a phone number) 
@S The speed dial number of the selected phone number 

{generates an error if the selected icon is not a phone number) 
@r The ring tone for all numbers in the selected entry 
@R The ring priority for all numbers in the selected entry 
@c The category for the selected entry 
@g The group within the category for the selected entry 
@@ A single '©* character. 



[0420] phone recentcall?filter-number&editkey-n, 
editlabel/storelabel&callkey=n,label&width=n 
&height-n&noempty 

[0421] Returns a stream that contains an embedded object 
that can display the list of recently-received or -placed 
phone calls. Each item in the list of calls has a set of flags 
associated with it. The object can be told to display only 
items that have a certain flag set. The one flag currently 
defined is bit 0, which marks a call from a number where the 
user failed to answer the call. 
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[0422] Parameters 

[0423] If filter is present, it indicates only calls of a 
particular type should be displayed (the sole current filter 
value is 1, meaning incoming calls that went unanswered), 
editkey and callkey specify a softkey whose label and action 
should be changed based on the call that has been selected. 
If noempty is present, it indicates that the screen containing 
the object should not be displayed if the list of calls, after 
filtering, is empty. 

[0424] Methods 



edit If the current selection is a number that is in the phone book, 
this 

brings up the phone book edit screen for the number, 
store If the current selection is not a number that is in the phone book, 

this brings up the new-phone book-entry sequence 

with the phone number set to the current selection, 
call Initiates a call to the number in the current selection, 
dismiss Closes the screen after clearing the "missed" flag (bit 0) 

for all items in the list. 



[0425] phone :ringtone?width=number&height= 
number&ptrAddr=hex 

[0426] Returns a stream that contains an embedded object 
that can display the list of ring tones the device can produce 
for an incoming call. 

[0427] Parameters 

[0428] If ptrAddr is given, the object gives the user the 
option of using the system-default ring. When the user has 
chosen a ring, its number is then placed at the memory 
address given by hex. IfptrAddr is not given, the object sets 
the system -default ring. 

[0429] Methods 



test Plays the selected nng tone tnrougn once. 

ok Sets the ring tone to that selected and closes the screen. 



[0430] phone :speeddial?width=number&height== 
number&ptrAddr=hexnumber&Name=string<&ic on=n 

[0431] Returns a stream containing an embedded object to 
display the list of speed dial locations. 

[0432] Parameters 

[0433] ptrAddr specifies where the object should store the 
selected speed dial number when the user chooses an entry. 
The Name and icon arguments are identical to those in 
phone :store, specifying the name and icon of the number 
being assigned a speed dial number. 

[0434] Methods 



ok Sets the speed dial number to the current selection, if the current 
selection is not currently assigned to another number, then closes 
the screen. The Name and icon arguments are used in building a 
confirmation screen for the user. 

clear Clears the assignment of the selected speed dial entry. 



[0435] (2) Content/Command URLs 

[0436] phone: active 

[0437] Returns a stream of type "CallManager" that 
causes the active-call screen to display, allowing the user to 
manipulate any calls that may be active. Does nothing if no 
calls are active. 

[0438] phone: answer 

[0439] Causes any incoming phone call to be answered, 
returning a stream that causes the active-call screen to 
display. Does nothing if no incoming phone call. The 
referring URL is popped from the URL stack if there was an 
incoming phone call. 

[0440] phonexonf 

[0441] Causes any incoming phone call to be answered 
and joined with the current active phone call. Returns a 
stream that causes the active-call screen to display. Does 
nothing if no incoming phone call. The referring URL is 
popped from the URL history stack 108 if there was an 
incoming phone call. 

[0442] phone:dial?num=string&name=string&icon= 
number&hidden 

[0443] Causes a voice call to be created to the indicated 
number. If name and icon are provided, they are used in the 
page that displays the call progress, and in any follow-up 
page where the user is asked if she wishes to add the number 
to the phone book. If hidden is specified, the user will not see 
the call once it has connected (the active call screen will not 
be displayed). The URL returns a stream that causes the 
call-progress screen to be displayed. 

[0444] If no arguments are given, the URL returns a 
stream that causes a dialer screen to be displayed, allowing 
the user to enter a phone number to call. 

[0445] If the page issuing the request lacks sufficient 
privilege, the user will be asked if it is permissible to dial the 
phone number. For example, a received text message lacks 
sufficient privilege, as it might contain a call to a 900 or 
long-distance number that the user is not aware of. 

[0446] phone: display?id=number 

[0447] Returns a stream that displays the Data field of the 
specified phone book record. 

[0448] phone: ecu't?name=string&num=string&offset= 
number&id=number 

[0449] Returns a stream that causes a new/edit screen of 
the phone book to be displayed with the passed parameters. 
Offset and id are used only internally to edit an existing 
record (offset indicates which phone number to edit, while 
id is the identifier of the record to edit). Name and num, 
however, can be used to create a new phone book record, 
giving the user a chance to select an appropriate icon and 
otherwise edit the entry before storing it in the phone book. 

[0450] phone:firstopen?password-string 

[0451] Checks the given password string against that 
stored in the configuration settings. If it matches, the refer- 
ring screen is popped and replaced by phone: main. If it does 
not match, the phone is turned off. This allows the power-on 
security screen to be an HTML page. 
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[0452] pbonerignore 

[0453] Causes any incoming phone call to be rejected. The 
referring URL is popped from the URL history stack 108 if 
there was an incoming phone call. Does nothing if there is 
no incoming call. No stream is returned, so the URL that was 
active before the referring URL was fetched is redisplayed. 

[0454] phone :indir?url=string&pop= action 

[0455] Fetches one or more URLs (which activates their 
side-effects, whatever they may be) before returning the 
stream from the last one fetched. If the pop argument is 
given, it indicates that one or more URLs should be removed 
from the URL history stack 108 before the returned data are 
displayed, action can be one of pop, abort, or clear, to 
remove one URL, all the URLs in the current interaction, or 
all URLs from the history stack 108. 

[0456] phone:look?cat=number&sort&form=format 

[0457] Retrieves names from the phone book that are in 
the category whose number is given by the cat argument. If 
the sort argument is given, the results are sorted alphabeti- 
cally. The form argument specifies in what format the data 
are to be provided. They are always in some form of HTML 
(the result of this URL is an HTML stream), but the tags 
used vary as follows: 

[0458] link: each entry name is formatted as a link to 
the appropriate place: for an entry with a Service 
field, the HREF is the contents of the Service field, 
while for an entry with a Data field, the HREF will 
show that data. All other entries dial the first number 
in the entry. 

[0459] form: the names are formatted as <OPTION> 
elements of a <SELECT> list (which must surround 
the <INC> tag that fetches this data). The value of 
each option is the URL, as described for link. 

[0460] menu: each entry is provided as a <KEY- 
MENU> tag in the same manner as for link. The key 
to use is specified by form=menu=x, where x is the 
key. 

[0461] count: produces the number of records that are 
in the given category. 

[0462] The phone: look URL, when combined with the 
new <INC> tag, allows an HTML page to display a subset 
of the phone book in some sort of branded, graphical 
context. More importantly, it provides a simple way for both 



a service operator and for the user to manage which services 
are available to the user. Groups of services are stored in the 
phone book with a particular category. The device then has 
a page that uses this URL to display those entries and allow 
the user to select one of the services. Adding and removing 
services are simply a matter of adding or removing an entry 
in the phone book; there is no need to modify the page that 
displays the list of services. 

[0463] phone :main 

[0464] Returns a stream that causes a predefined main 
screen to be displayed. 

[0465] phone:release?id=number 

[0466] Releases the active call, or the specified call if the 
id argument is given. Returns no data. 

[0467] phone:shortcut?num=n 

[0468] Activates a shortcut function, n ranges from 0-9. 

[0469] Shortcuts are defined by the manufacturer of the 
wireless communication device 100, and are typically acti- 
vated by holding down one of the softkeys 130 and then 
pressing one of the numeric keys 134. They are generally 
available from all screens, with the exception of the power- 
on password screen. 

[0470] For example, shortcut 1 might lock or unlock the 
keypad, while shortcut 2 might mute the phone's ringer, and 
shortcut 3 might activate or disable password protection 
when the wireless communication device 100 is turned on. 
Certain shortcuts might also be restricted on certain screens 
other than the power-on password screen. 

[0471] phone:store?Name=string&Phone=speed=icon= 
string&Owner=string&Service=url&Catego 
ry=number&Group=number&Ring=number&Data= 
type % Oadata&speed=speed&icon=i con&id= 
id&oflset^number&prio =n&pop=string 

[0472] Creates, augments or edits a record in the phone 
book. If id and offset are specified, the selected phone 
number in that record is edited. Otherwise, if a record with 
the same Name already exists, the record is augmented, 
while an unmatched Name causes a new record to be 
created. 

[0473] Parameters 



Phone The contents of this parameter vary depending on whether the 

"speed" and "icon" parameters are specified. 
If they are not specified, this parameter contains a string of the 
form "spccd=icon=numbcr/speed=icon=number/. . In other 
words, a string that specifies one or more phone numbers, giving 
the speed dial location and icon to associate with each. 
If "speed" and "icon" are specified, this parameter contains only 
the single phone number to store in the phone book. 

Owner Specifies a password that allows the contents of the entry to be 

updated over the air. 

Service Specifies a URL to be stored in the entry. This URL appears like a 

phone number in the phone book, but when the Send key is 

pressed, the data for the URL are fetched. 
Category Allows an entry to be hidden from the normal phone book screen, 

but found by the phone :look URL for inclusion in an HTML page. 

Categories 0,1, and 2 are displayed by the norma] phone book. 
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-continued 



Ring Specifics a ring tone (0 to 127, with 0 meaning to use the system 

default) to use when a call arrives from any number in this phone 
book record. If the high bit (32768) is set, it indicates that calls 
coming from any number in this phone book record should ring 
through, even if the device is in quiet mode. The high bit can also 
be set using the pric argument. If this is 1, the high bit will be set. 

Data Allows arbitrary data to be stored in a phone book record. The data 

appear like a phone number in the phone book, but when the Send 
key is pressed, the data are displayed. The first part of the argument 
value is the type of data. Typically this will be either text or 
HTMLp. The second part is the data itself, as a string of hex digits, 
two per octet to be stored. 

Pop (Optional) Causes the URL that requested the phonestore UIRL to 

be removed from the URL history stack 108 according to the string 
value (pop => just the URL is removed, done => all URLs back 
beyond the most recent top URL are removed, and clear => all 
UIRLs back to the main screen are removed). 
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[0474] This particular command provides significant flex- 
ibility to the user. First, the DATA argument allows any data, 
not just telephone numbers, to be stored in the phone book. 
In particular, URLs, images, audio data, and any other 
content may be stored, creating a general purpose database 
in the wireless communication device 100. For example, a 
user may be viewing Web content, select a URL that is 
displayed, and immediately store it to the phone book for 
later recall. 

[0475] Second, the RING argument allows different ring 
tones to be specified for each phone book entry. This RING 
tone will be used when an incoming call is received from 
any number in that phone book entry. This allows the user 
to specify particular, distinct ring tones for various telephone 
numbers. For example, the user may specify particular ring 
tones for different family members, co-workers, a doctor's 
office or the like. 

[0476] Third, the RING argument also allows for priority 
ringing for any phone book entry and its ring tone, by setting 
the high bit of the ring tone value, or specifying a non-zero 
PRIO argument. A conventional wireless communication 
device typically includes a quiet mode that silences the 
telephone and normally prevents it from ringing for any 
incoming call. With the present invention, this RING argu- 
ment can specify that calls from the phone book entry are not 
so blocked, and allowed to ring. Thus, the user may set this 
priority ringing for family members and other important 
persons, so that even during quiet mode, telephone calls 
from such persons are allowed to ring. 

[0477] The call manager content handler 1146 implements 
this feature by comparing the telephone number of each 
incoming telephone call with its store telephone numbers, 
and using the specified ring tone (if any) to select and control 
the ringing of the phone. 

[0478] b) The message Protocol 

[0479] Text messages, similar to alpha-numeric pages, can 
be received and viewed using the present invention. Mes- 
sages are stored in a file and identified by a unique identifier. 
This protocol is handled by the message protocol handler 
112/. 

[0480] (1) Embedded Objects 

[048 1 ] message: li st?width=number&heigh t= 

number&type=type&num=string&lockkey=n,lockla- 

bel /unlocilabel 
[0482] Returns a stream containing an embedded object 
that displays a list of the messages of the given type. 



[0483] Parameters 



num (Optional) Indicates that only messages ftom the given source 
are to be displayed. 

lockkey (Optional) Specifies which softkey 130 is to be updated based on 
whether the selected message is currently locked; 
pressing that softkey will toggle the locked state 
of the message. The locklabel and unlocklabel portions 
of the parameter specifY the label to be given to 
the softkey 130 based on the function it is then performing. 

type (Optional) Specifies what type of messages are to be displayed. 
Possible values are "TEXT", "FAX" or "VOICE". 



[0484] Methods 



lock 
unlock 



new 
open 



Locks the selected message against automatic deletion. 
Unlocks the selected message, allowing it to be 
automatically deleted. 

Begins composing a new outgoing message. 
Displays the selected message and marks it as read. 



[0485] Any URL that contains an @ is also considered a 
method for this object. It is searched for the following 
escapes; if an escape is found, it is replaced by the relevant 
piece of data from the current selection. Once all escapes 
have been substituted for, the resulting URL is fetched. 
TABLE 3 



Escapes for Messages 



Escape Replaced By 



@i The record [D of the selected message 

@b The body of the selected message (URL-encoded) 

@n The phone number to call if one wishes to reply to the 

message by voice. For a numeric page (a message with just a 
phone number in it), this will be the number in the page. For 
all other messages, this is the phone number of the message 
sender. 

@s The phone number of the message sender 
@@ A single 4 @* character 



[0486] (2) Content/Command URLs 

[0487] message: count?type=type 

[0488] Returns a stream that contains the number of 
messages that are waiting, as text. The possible type values 
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are VOICE, TEXT, or FAX. Usually this is used with the 
<INC> tag in implementing an inbox for all types of 
messages, providing a list of the types of messages the 
device supports, where the list enables the user to get to the 
individual screen for that type of message. The list can use 
this URL and the <INC> tag to display the number of 
messages available on this screen as part of the text that 
makes up the list. The URL can also be used in the TEST 
attribute of an IF tag to select a different <IMG> tag based 
on whether there are any messages of that type available. For 
example, a static image could be used when there are no 
messages, while an animated one is used when there are 
messages of that type available. 

[0489] message :operate?reply»&delete=&lock=&un- 
lock-&adjust-&id- number 

[0490] Performs an operation on the message whose id is 
specified. The possible operations (only one of which may 
be specified in the URL) are: 

[0491] reply: causes the message-composition screen 
to be brought up, with the destination address set to 
the sender of the message whose id is specified, 

[0492] delete: causes the message to be deleted. 

[0493] delconfirm: causes the message to be deleted 
after the user has been asked to confirm the deletion. 

[0494] lock: causes the message to be marked locked, 
which prevents it from automatically being deleted 
when the message store is full. 

[0495] unlock: causes the message to be marked 
unlocked, which allows it to be automatically deleted 
when the message store is full. 

[0496] If the adjust argument is given, it causes the URL 
history stack 108 to be adjusted in the following manner: 

[0497] reply: no adjustment is made. 

[0498] delete: the referring URL is popped from the 
URL stack 

[0499] lock, unlock: a stream from the message :read 
URL is returned for the message, replacing the 
referring URL. 

[0500] This URL requires sufficient privilege to operate. If 
the referring URL lacks the privilege, the operation is 
confirmed with the user. 

[0501] message: read? id=number 

[0502] Returns a stream to display the message whose id 
is passed. The stream is for a template HTML file. The 
parameters that fill in that template are returned based on the 
contents of the message. 

[0503] message :send?addr~string&body- 
string&newaddr=&newbody=&pop=&reply=id 

[0504] Requests that a text message be sent to the indi- 
cated address. If addr is missing, or newaddr is present, this 



returns a stream and parameters that allow the user to set the 
address for the message, while maintaining any body that 
was given. 

[0505] If body is missing, or newbody is present, this 
returns a stream and parameters that allow the user to add or 
edit a body for the message, while maintaining any addr and 
reply that were given. 

[0506] If both addr and body are given, and both newaddr 
and newbody are absent, the message is sent. If reply is 
given, the corresponding message is marked as having been 
replied to. 

[0507] If the message is sent, and pop is present, the 
referring URL is popped from the URL history stack 108. 

[0508] This URL also operates with the POST operation 
(PutURL), where the addr is specified in the URL and the 
stream of data to put to the URL are taken to be the body of 
the message. 

[0509] This URL requires sufficient privilege to operate. If 
the referring URL lacks the privilege, the operation is 
confirmed with the user. 

[0510] c) The config Protocol 

[0511] The third protocol for interaction with device func- 
tions is the config protocol, which is used to set and get 
device configuration information. This protocol is handled 
by the config protocol handler 1126. 

[0512] The URLs that are formed with this protocol are 
the device settings themselves. When a URL is fetched, the 
current setting of the URL is converted to text and returned 
as a stream. When data are posted to a config protocol URL, 
the data are converted as necessary and the device setting is 
set. A config URL may address bits within a device setting, 
both for getting and setting. The URL then looks like this: 

[0513] config:setting.bitnumber:bitsize 

[0514] If:bitsize is not present, 1 is assumed. 

[0515] Bitnumber runs from 0 to 31, with 31 being 
the most-significant bit. 

[0516] Most settings may be fetched by any module, 
though some (like the wireless communication device's PIN 
number) may only be obtained by pages with sufficient 
privilege (typically HTML files that are in the ROM memory 
126). No device setting may be set without sufficient privi- 
lege (again, typically by HTML files that are in the ROM 
memory 126). 

[0517] Multiple settings can be set by posting to "config- 
:set". The stream then contains lines of the form "setting- 
.bitnumbenbitsize/value" 

TABLE 4 



Configuration URLs 
URL TYPE FUNCTION 



config Jceypadlock Boolean Engages or disengages keypad lock, when set, 
configtsmspriority intl6 Rates how important incoming messages are: 0 => 

display all messages, 1 «> display messages with the 
smsteyword, 2 »> put alt messages in the inbox 
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TABLE 4-continued 



URL 


TYPE 


co nfig :smskeyword 


chart 16] 


config:ringtonc 
config:ringrnodc 


intl6 
intl6 


co ofig :sctquictmodc 


boolean 


config:quietmode 


intld 


conflg:setpassword 


boolean 


conflg:password 
coDflg:backlight 


chart 4] 
boolean 


co nfig :key clicks 


boolean 


config:autosearch 


boolean 


co nfig :f olio wup 


boolean 



Configuration URLs 
FUNCTION 



coafig:lasttime 
configitotaltime 



intl6 
int32 



Specifies a word to look for in incoming messages to 

determine if they are important enough to display. 

Specifies a ring sequence (1-127) to use by default. 

Specifies how to ring the phone: 0 => periodic 

ringing, 1 => periodic ringing +vibration, 2 => ring 

only once, 3 «> do not ring at all. 

When set, only calls from high-priority numbers will 

cause the phone to ring in its normal way. 

Specifies how to ring the phone for non-high priority 

numbers when in quiet mode. 0 => vibrate, 1 => 

chirp, 2 => don't do anything. 

When set, causes the user to be asked for a password 

whenever the phone is powered on. 

The password that must be entered. 

If true, then backlight is turned on when the phone is 

in-use. 

If true, then keystrokes generate a clicking sound 
appropriate to the key that was hit 
If true, the phone book is searched for matches as the 
user dials the phone. 

If true, and a call is made to or received from a 
number that is not in the phone book and that hasn't 
been called recently, the user is asked whether to put 
the number in the phone book. 
The number of seconds the last call was connected. 
The total number of seconds that spent connected. 



[0518] d) The "extra" Protocol 

[0519] The "extra" protocol is used primarily with the new 
<INC>, <1F> and <TEMPLAXE> tags to enable HTMLp 
templates to function as the bulk of the user interface of the 
present invention. This protocol is handled by the extra 
protocol handler 112c. 

[0520] Generally, extra parameters are passed to an 
HTMLp template either from: 

[0521] 1) the C code of the MMI 102. 

[0522] 2) as an arguments string to a file URL. This 
takes the form "file://filename?variablename=extra- 
_data". The extra data is stored with its variable 
name and used to complete the HTML for whatever 
page is fetching filename. 

[0523] 3) as data from a previous form that used the 
new METHOD =NEXT attribute to pass the form 
data to the next URL. 

[0524] In addition, when a URL that is in an HTMLp page 
is fetched and it has no arguments, any parameters that were 
passed to the page that contains the URL being fetched are 
also passed to the URL that is being fetched. 

[0525] The extra protocol handler 112c looks for an argu- 
ment that matches the URL and converts the argument to a 
stream. For example, "<INC src=extra:body>" will include 
the "body" argument into the HTMLp stream. As another 
example, assume there is an HTMLp page that is used to 
display a message in a standard format with standard graphi- 
cal elements. The message to display is given as an argument 
for the URL that loads the HTML page. 

[0526] For example the URL 

[0527] "file://message.html?message=Please+enter+ 
a+valid+phone+number" 



[0528] when given to the extra protocol handler 112 will 
stores the text "Please enter a valid phone number" as a text 
string with variable name "message." This extra data will be 
displayed in any other page by use of the "extra: message" 
URL, which will output the string data. FIG. 22 illustrates 
this use. In this example, the extra data is retrieved by use 
of the <INC> tag, and results in the text string being directly 
incorporated into the page. 

[0529] Generally, the extra protocol handler 112c is 
invoked as a result of the HTMLp content handler 114c 
parsing an "extra" URL in a HTMLp page. When so 
identified, the URL is passed to the extra protocol handler 
112c for decoding and retrieval of the extra data, which is 
returned to the HTMLp content handler 114c to render into 
the page. 

[0530] e) The builtin Protocol 

[0531] The builtin protocol provides access to built-in 
icons and images for use in the SRC attribute of an IMG tag. 
These icons and images are stored in the ROM of the 
memory 126. The "builtin" text forms the protocol compo- 
nent of the URL, and the name of the desired icon makes up 
the data component of the URL. FIG. 23 illustrates a 
preferred set of icons, and the full URL for specifying them. 

[0532] Generally, the builtin protocol handler 112a is 
invoked as a result of the HTMLp content handler 114c 
parsing a "builtin" URL in a HTMLp page. When so 
identified, the URL is passed to the builtin protocol handler 
112a for decoding and retrieval of the icon or image data 
from memory 126, which is returned to the HTMLp content 
handler 114c to render into the page. 

[0533] C. PORTABLE COMPONENTS 

[0534] Referring again to FIG. 3, the portable components 
116 are a set of user interface entities and other functional 
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components that are used to implement the user interface 
and storage needs of the wireless communication device 
100. The components write to the APIs provided by the 
portability layer 118, and they serve as the basic implemen- 
tation elements of the MMI 102 while remaining portable 
for use with different wireless communication devices 100. 

[0535] 1. Graphics 

[0536] The graphics system 224 divides the screen display 
136 into sections called windows. Windows are arranged in 
a hierarchy, where child windows are wholly contained 
within their parent window. However, unlike other window 
systems, the window system of the present invention dis- 
tinguishes between two types of windows: "dull" and 
"sprite". Rather than having every user interface component 
and window have its own bitmap as in conventional systems, 
which requires more complex bitmap handling, the graphic 
system 224 takes advantage of the fact that user interface 
components generally do not overlap. Instead, the graphics 
system 224 defines some windows (e.g., dialog boxes, or 
other windows that do overlap with other windows and need 
to obscure them) to have a bitmap (to be "sprite"), while the 
others (the "dull" windows) draw into the bitmap of their 
nearest ancestor that has one. This distinction reduces the 
amount of memory needed to store user interface compo- 
nents, and simplifies the process of updating the screen 
display 136. 

[0537] When a user interface element draws to a window, 
the drawing actually happens to a bitmap in memory 126, 
not directly to the screen display 136. At some point (in the 
top loop, actually, where the callback queue 110 is pro- 
cessed) all the changes to any and all of these bitmaps are 
transferred to the screen display 136. This operation ensures 
a correct and clean update of the screen display 136, and 
simplifies the underlying video driver, which need only 
transfer the bitmap from memory 126 to the screen display 
136, 

[0538] The graphic systems 224 provides the following 
basic graphic primitives: 

[0539] Lines (thick or thin, arbitrary or special-cased 
single-pixel-thick vertical and horizontal; horizontal 
lines, vertical lines, and rectangles can also have a 
fill pattern to let them be dotted or dashed); 

[0540] Rectangles (outline or filled); 

[0541] Bitmaps (single-bit-per-pixel, drawn either as 
a stencil [a set bit gets drawn in a color, while a clear 
bit does nothing] or as an image [a set bit gets drawn 
in one color, while a clear bit gets drawn in another]); 
and 

[0542] Text. 

[0543] The coordinate system of the screen display 136 is 
such that coordinates fall between pixels on the screen 
display 136. The result is that if rectangle is drawn from (a, 
b) to (c, d) and another from (c, b) to (e, d), they will not 
overlap. 

[0544] Text is drawn and manipulated using a data struc- 
ture called a TextState. Text has various configurable 
attributes: 



[0545] Point size (preset small, medium, and large); 

[0546] Style (plain, bold, italic, underline, fixed- 
width and strike -through); and 

[0547] Color. 

[0548] TextState also stores the drawing position, which is 
updated to be just after the string that was drawn, so that 
multiple strings may be drawn one after another without 
having to compute their width. 

[0549] 2. User Interface Gadgets 

[0550] Most of the user interface of a wireless communi- 
cation device 100 may be provided in the form of softkeys 
130 and softkey menus. The content area 214 will generally 
display text, icons, and HTML forms, and the like. To 
support these features, a number of user interface gadgets 
226 are provided: 

[0551] Checkbox: used to implement both check- 
boxes and radio buttons (radio buttons rely on an 
external callback to know the other radio buttons that 
need to be deselected when the user selects one) 
Instantiated in response to <INPUT TYPE-check- 
box> and <INPUT TYPE=radio> in HTML. 

[0552] Icon: displays a built-in icon. 

[0553] LabelLine: a horizontal line with an optional 
text label in a standard location in a standard font. 
Instantiated by the <HR> tag in HTML. 

[0554] List: the basis for all the various lists of items 
in the user interface. Specific list subclasses draw the 
individual items (placed by the List) and determine 
when the List's selection should be adjusted by a 
keystroke or other means. 

[0555] Popup: implements a popup list of strings 
from which the user can select one or multiple items. 
Each item has a string value bound to it. Instantiated 
by the <SELECT> tag in HTML when the SIZE 
parameter is 1. 

[0556] ScrollBanner: implements a single-line text 
banner that can scroll from right to left or from left 
to right at a specified speed. Instantiated by the 
<MARQUEE> tag in HTML. 

[0557] StringList: implements the list part of the 
Popup, but can also stand alone as a scrolling list. 
Softkey menus are implemented by a StringList. 
Instantiated by the <SELECT> tag in HTML when 
the SIZE parameter is not 1. 

[0558] TextEdit: a single-line or multi-line text edit- 
ing area. Instantiated by the <INPUT TYPE=text> 
and <INPUT TYPE=password> tags in HTML. 

[0559] These entities are created as needed by the various 
modules to display various graphic elements. 

[0560] These various types of user interface elements are 
created by the HTMLp content handler U4c when a page is 
parsed and in response to corresponding HTML tags. For 
example, an INPUT TYPE=TEXT tag in a page will result 
in a TextEdit object at the appropriate location on the screen 
display 136. When the user selects the object with the Up or 
Down key, it is given the input focus to receive keystrokes 
input by the user, as such keystrokes are passed by the shell 
106 to the TextEdit object. 
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[0561] Associated with the user interface gadgets are a 
couple other modules for entering and displaying text. The 
TextEntry module 228 accepts keystrokes and maps them to 
commands for text input. The commands include displaying 
provisional (subject to further modification based on subse- 
quent keystrokes) characters and words, and replacement 
provisional characters and words, making the last provi- 
sional character or word final, and moving the cursor or 
inserting symbol characters. 

[0562] Any entity requiring text input registers with the 
TextEntry module 228 and then passes nearly all keystrokes 
to it, rather than interpreting the keystrokes itself. Front-end 
processing for various pictographic languages is handled in 
this module, as well. 

[0563] Another module is the TextWrap module 230, 
which handles arbitrary regions and wraps text and objects 
inside those regions. This module is primarily used in 
displaying HTML content, but can also be used for list 
entries that are allowed to wrap over multiple lines. 

[0564] 3. Data Store 

[0565] Another element of the implementation is the data 
store 232. The data store 232 is a simple "flat-file" database 
with the following characteristics: 

[0566] Up to 255 fields per record. Fields have both 
a name and a number, but only the number is used for 
actually accessing the data. 

[0567] All records are defined to logically have all 
fields. As a storage optimization, if no data have been 
given for a particular field for a particular record, the 
field for that record takes up no space. 

[0568] Each record has a unique identifier (16-bits at 
the moment) that is used to gain access to the record. 

[0569] Database records are not manipulated directly. 
Instead, functions to get and set the fields of a record 
are used. 

[0570] A database can have up to eight indices main- 
tained for it. Each index has a selection routine and 
a comparison routine. The selection routine deter- 
mines which records are part of the index, while the 
comparison routine is used to sort the records in the 
index. When the index is defined, it specifies which 
database fields are used by the selection and com- 
parison routines. When a record is altered, only if 
one of those fields is changed will the record be 
repositioned in, added to, or removed from the index. 

[0571] To access a record, one of two functions is 
called to get a DataStoreRecord token. When an 
entity is done examining or manipulating the record, 
it calls DataStoreRecordDone. 

[0572] 4. File Systems 

[0573] The wireless communication device 100 has a file 
interface that communicates with two underlying file sys- 
tems: 

[0574] A read-only filesystem that is a data structure 
compiled into the code. 

[0575] A flash filesystem that is spread among flash 
memory chips of the wireless communication device 
100. 



[0576] File access is via a (minimal) familiar set of 
functions: 



[0577] 
[0578] 
[0579] 
[0580] 
[0581] 
[0582] 
[0583] 
[0584] 



FileOpen 

FileCreate 

FileRead 

FileWrite 

FileSeek 

FileTruncate 

FileClose 

FileDelete 



[0585] Each file system is defined by a structure contain- 
ing routines to call for all the basic operations. The reference 
for an open file contains file system-specific data and a 
pointer to the table of routines for the file system on which 
the file sits. When a file is opened, the upper layer examines 
the name of the file to be affected and chooses the appro- 
priate table of routines, then uses the Open routine in that 
table to open the file. Thereafter, access to the file is through 
the file reference. 

[0586] D. Portability Layer 

[0587] Referring again to FIG. 3, there is shown the 
various modules of the portability layer 118. The portability 
layer 118 is designed to make it relatively simple to imple- 
ment the MMI 102 with an arbitrary telephone control 
module 120 and real time operating system 122. It provides 
the following modules: 

[0588] 1. Call Control 

[0589] The call control module 140 allows the upper 
layers to create and manipulate calls, generate DTMF tones, 
and receive notification of state changes. 

[0590] The interface is asynchronous, in the sense that 
operations are performed on calls, but the success or failure 
of each operation is reported some time after the operation 
was requested. 

TABLE 5 



Call Control Functions 



FUNCTION 



PURPOSE 



CallCreate Attempts to begin a telephone call, given the number 

to dial. The call can be voice, or data, or fax. 
CallCreateHidden Like CallCreate, but signals that the call should not 

be visible to the user. 
CaHRelease Attempts to hang up a call If the call is part of a call 

group (conference), the entire group is hung up. 
CallHold Attempts to put a call (or call group) on hold. 

Call Resume Attempts to take a call (or call group) off hold. If 

another call or call group is currently active, it is 

placed on hold first 
CallCombine Attempts to join an on-hold call with the currently 

active call or call group to form a new or larger call 

group. 

CallS eparate Attempts to extract a call from a call group, making 
it a separate call again. 

CallGetinfo Retrieves various pieces of information about an 

active call, such as what actions may be performed 
on it, its current state, to what number it's connected, 
the time when it connected, the time when it was put 
on bold, and whether it should be hidden from the 
user. 
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TABLE 5-coatinued 



TABLE 7- continued 



Call Control Functions 



FUNCTION 



PURPOSE 



CallPickup 
CallStaitSequence 



CallEndSequence 
CallStartDTMF 

CallEndDTMF 

CallEnumerate 

CallData 

Available 

CallDataRead 

CallData Write 

CallSetNotify 



Attempts to answer an incoming call. 

Marks the start of a series of call manipulation steps 

that depend on each other. If one of the steps fails, 

the rest of the steps in the sequence arc not 

attempted. 

Marks the end of a series of call manipulation steps. 
Begins generating a DTMF tone corresponding to a 
particular key. 

Stops generating the DTMF tone that was previously 
started. 

Calls a function for each active call in the system. 
For a data call, returns the number of bytes available 
for reading. 

For a data call, reads available data. 
For a data call, writes data to the network. 
Specifies the routine to be called at the end of each 
call operation and when various asynchronous events 
occur, such as the arrival of an incoming call. 



[0591] 2. Message Control 

[0592] The message control module 142 allows the upper 
layers to transmit and receive short text messages. This layer 
may or may not support segmentation and reassembly of 
larger messages. 

TABLE 6 



FUNCTION 



Message Control Functions 



PURPOSE 



Given the various parameters of a text message 
(destination number, body data, body format, and 
options), returns an SMS token for the message 
that can then be sent 

Takes a string of URL-encoded arguments and 
uses them to create an SMS token for the 



SMSCreateFromURL 



SMS Send 



SMSDestroy 



message. 

Takes an SMS token and sends the associated 
message. Notification function is called when the 
message has succeeded or failed in its attempt at 
sending. 

Frees the memory used by an SMS token. 



[0593] 3. Platform 

[0594] The platform module 144 provides for platform- 
specific functions. 



TABLE 7 



Platform Functions 



FUNCTION 



PURPOSE 



PlatMutex- Initializes a variable that can guarantee exclusive 

Initialize access when passed to PlatMutexOrab. While the 

MMI 102 is single- threaded, there arc pieces of the 
portability layer 118 that may run on a different 
thread. Those parts of the upper layers that might be 
called from a different thread (where interrupt- 
handling code is also viewed as a separate thread) 
use this mechanism to guarantee exclusive access to 
data structures. 

PlatMutexGrab Gains exclusive access to whatever is governed by 
the mutual exclusion variable initialized by 
PlatMutexInitialize. 



Platform Functions 



FUNCTION 



PURPOSE 



PlatMutexRelease 



PlatMutexDestro y 

PlatWaitFor- 
Something 



PlatHave- 
Something 
PlatRingPlay 



PlatRingStop 

PlatRingGet- 

NumberOfRings 

PlatRingGetName 



PlatGetPower- 
Status 



Releases exclusive access to whatever is governed 

by the mutual exclusion variable initialized by 

PlatMutexInitialize. 

Frees up any resources allocated by 

PlatMutexInitialize. 

Pauses until PlatHaveSomething is called. This 
provides a hook for the portability layer 118 to shut 
down or yield control of the processor, so the upper 
layers do not waste processor time unnecessarily. 
Releases the upper layer if it is waiting in 
PlatWaitForSomething. 

Plays a ring tune or other sound through the system's 
speaker. Sounds are defined by an index, a volume 
level, and whether vibration should also happen. 
127 sounds are defined as system sounds (keyclicks 
and error sounds, for example), while 127 sounds are 
defined as tunes for the phone ringer. Returns 
immediately, allowing the sound to play in the 
background. 

Interrupts an active sound that was started with 
PlatRingPlay. 

Returns the number of phone ring tunes that are 
supported/defined. 

Returns the name of one of the phone ring tunes, for 
displaying to the user to allow her to select a default 
ring, or a ring for a particular person. 
Retrieves the current state of the battery and AC 
adapter. 



[0595] 4. Timer 

[0596] The timer module 146 provides basic timing ser- 
vices that allow the upper layers to receive a function call 
after a specified amount of time has passed. 

TABLE 8 



Timer Functions 



FUNCTION 



PURPOSE 



Timer Alloc Allocates a timer that can be used repeatedly. Sets 

the routine to be called when the timer expires. The 
routine is called synchronously via the callback 
queue; it does not interrupt other operations. 

TimerStart Specifies the next timeout interval for the timer, in 

milliseconds. After approximately that amount of 
time, the routine specified in Timer Alloc is called. 

TlmerStop Stops a timer from firing. If the timer has already 

fired, and a call to the timer routine is in the callback 
queue, the call is removed from the queue, so there is 
no need to handle getting a call after having stopped 
the timer. 

TimerFree Frees up an allocated timer. If the timer was running, 

it is also stopped. 

TimerGetSeconds Returns a 32-bit counter of seconds. The counter 

does not need to be relative lo anything in particular, 
so long as it increases steadily once each second. 



[0597] 5. Display 

[0598] The display module 148 manages the screen dis- 
play 136. 
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TABLE 9 



FUNCTION 



Display Functions 
PURPOSE 



Copies part of a bitmap to a point on the 



Display Driver Blitln 



Display SetBacklight Turns the display's backlight on or off. 

Display Driver SetContrast Sets the display's contrast to the specified 
value. 

Display DriverGetContrast Retrieves the current contrast for the display. 



[0599] 6. Flash Driver 

[0600] The flash driver module 150 allows the upper layer 
file system module 234 to read and write the flash memory 
chips on the wireless communication device 100. 

TABLE 10 



Flash Drive Functions 



FUNCTION 



PURPOSE 



FlashDriverlnitialize Initializes access to the flash memory. 

FlashDriverGetlnfo Returns information about the flash driver and the 
device it is driving. It includes: 
The number of erase units in the device 
How big each erase unit is 

If the device reads and writes in pages, rather than 
on arbitrary byte boundaries, the driver can 
specify the page size. 

If either the device or the driver supports error- 
correction for written pages, the driver can 
indicate this to the flash file system. 

FlashDriverErase Erases an erase unit of the device. It may happen 
synchronously or asynchronously, but in either 
case a callback function is called when the erase 
is complete, indicating if the erase was successful. 

FlashDriver Write Writes a number of blocks of bytes to an erase unit 
in the device. If the device reads and writes in 
pages, the size of the blocks will always be a page 
size, though the driver may have to provide harm- 
less bytes for one ox more of the blocks that make 
up the page. 

FlashDriverRead Reads a number of bytes from an erase unit in the 
device. 



[0601] 7. Config Protocol Handler 

[0602] This protocol handler 1125 allows C code and 
HTML to get and set configuration settings of the wireless 
communication device 100. These settings are the ones 
implemented by the upper layers, and the module commu- 
nicates other settings to lower-level code as needed. Because 
of its need to access configuration settings, the config 
protocol handler H2b is preferably located in the portability 
layer 118. 

[0603] A config URL may address bits within a device 
setting, both for getting and setting. A config URL has the 
following syntax: 

[0604] config:setting.bitnumber:bitsize 

[0605] If :bitsize is not present, 1 is assumed. Bitmimber 
runs from 0 to 15, with 15 being the most-significant bit. 

[0606] Most settings may be fetched by any module or 
page that needs them, though some configuration setting, 
such as the telephone's PIN number, may only be obtained 



by URLs with sufficient privilege (typically HTML files that 
are in the device's ROM). No device setting may be set 
without sufficient privilege (again, typically by HTML files 
that are in the device ROM). 

[0607] The following are a set of preferred configuration 
URLs for invoking respective functions of the config pro- 
tocol handler 112b: 

TABLE 11 



FUNCTION 



Config Protocol Handler Functions 
PURPOSE 



ConflgGetInt\felue 
Co nftgSetlnt Value 
Co nfigGetString Value 
ConfigSetString\klue 
Co nfigParseSetting 



Co nfigCheckPassword 
Co nflgCon firmPassword 



Retrieves an integral configuration setting. 
Sets an integral configuration setting. 
Retrieves a string configuration setting. 
Sets a string configuration setting. 
Parses a string reference to a configuration 
setting, yielding the data type of the setting, 
and, for integral settings, which bits of the 
value to affect or fetch. 
Examines the arguments from a URL for a 
password and compares it against the password 
stored in the configuration settings. 
Handles obtaining a password from the user 
and resubmitting a URL with a password 
attached (to be examined by 
Co nfigCheckPasswo rd) 



[0608] In summary, the present invention provides a sys- 
tem, various methods, and a software product that substan- 
tially enhances the flexibility and functionality of wireless 
communication devices. The present invention, including 
the use of protocol handlers and content handlers, provides 
a system and software architecture in which all features and 
functionality of the wireless communication device may be 
accessed and manipulated through a markup language based 
user interface. The extended features of HTMLp and the 
HTMLp content handler specifically allow Web and other 
content to be easily displayed on the small screen display of 
a wireless communication device, and enhance the menuing, 
navigational features, and the form handling features of 
HTML. By providing access to telephone or other function- 
ality of the wireless communication device through a 
markup language-based user interface, the present invention 
allows service operators to easily and quickly generate new 
user interfaces and custom feature sets for different wireless 
communication devices, without requiring the expertise, 
software development environment, or software manage- 
ment problems of conventional MMIs. Further, the present 
invention allows service operators and manufacturers to 
quickly and efficiently brand wireless communication 
devices as desired, again without requiring creation of 
different MMI software for each service operator. 



Appendix A 



The Shell Functions 



[0609] The shell 106 offers many functions for the other 
parts of the present invention to use to process keys, manage 
the URL history stack 108, and handle other data. They are 
described briefly as follows: 
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-continued 



FUNCTION 



PURPOSE 



PURPOSE 



Shell ProcessKey 
ShellGrabinput 



KEY PROCESSING FUNCTIONS 

Accepts keystroke from the portability layer 
and passes it to the first entity in the 
keypad target list 
Registers an entity as interested in 
receiving keystrokes. The keypad target list 
is processed in UFO order. An entity is 
defined as a table of two routines plus a 
void * those routines can use for any 
purpose. The two routines are; 
ProcessKey, which actually receives the 
keystrokes. 

GrabChange, which is notified when the 
entity is or is not at the head of the 
keypad target list 

Unregisters an entity from the keypad target 
list. 

Passes the keystroke to the entity that 
registered before the one calling this 
function. When called from a content 
handler's ContentProcessKey function, the 
shell will process the keystroke according to 
the system-wide defaults. 
URI STACK MANAGEMENT 



ShellReleaseinput 
ShellPreviousinput 



ShellGetURLWithDataAnd 
Flags 



ShellGetURL 

ShellGetURLFlags 
ShellDisplayContent 



ShellGctURLStrcam 



ShellRerun 



ShellGoBack 



ShellGoBackString 
ShellPopURL 



Fetches the data associated with the URL 
and hands control of the content area to the 
handler for the type of content that is 
returned by the protocol handler, placing the 
URL at the top of the URL stack. 
In addition to the ContcntStrcam returned by 
the protocol handler, the content handler 
receives the ShellExtraData passed to this 
routine. 

The caller also passes a set of flags that 
contain the priority of the URL (how 
important it is to display the data; if the 
URL stack contains a URL that is of higher 
priority, the fetching and display of the 
data associated with the passed URL is 
delayed until the user has removed the 
higher-priority UERL from the stack) and 
the privilege level at which to fetch the 
passed URL. 

Fetches the data associated with the URL 
and displays it, passing no extra data and 
using the priority and privilege of the URL at 
the top of the URL stack. 
Gets the flags (priority and privilege) for 
the URL at the top of the URL stack. 
This is the moral equivalent of a dialog box 
in the present invention. It allows you to 
bring up a content handler directly without 
having to have a protocol handler and URL 
involved. The content handler receives the 
same flags and privilege as is enjoyed by 
the URL that is bringing it up. 
Fetches the data associated with the URL 
without changing what's displayed in the 
content area. 

Refetches the data for the top URL on the 
URL stack and causes it to be displayed 
again. 

Pops one or more URL's from the URL 

stack. The caller passes a parameter that 

says whether to simply remove the top- most 

URL, all URL's involved in the current 

interaction {see section (ii)) or all URL's 

but the very first. 

Like ShellGoBack, but accepts a 

dynamically-allocated string. 

Pops a specific URL off the URL stack. 



ShellMarkTop Marks the current URL as the start of a 

complex interaction, all components of 
which can be popped from the stack at 
once by passing the appropriate argument 
to ShellGoBack. 

ShellMarkTemp Turns on or off the "temporary" attribute 

of the top-most URL. When a URL is 
marked temporary, any attempt to fetch 
another URL will cause the temporary 
URL to be popped from the stack before 
the new URL is displayed. 

ShellPutURL Stores data for the passed URL. Does not 

affect the URL stack. 

ShellSetState Records a block of state to be associated 

with the top-most URL on the URL stack. 
The content handler for the URL is 
responsible for freeing and altering the 
contents of the block; the shell merely 
tracks the address. 

The intent is to allow the user to return to 
the same visual place when she pops back to 
this URL. The shell does not attempt to 
cache URL data returned by protocol 
handlers. 

ShellGetState Retrieves the block of state for the top-most 

URL, as was set by calling ShellSetState. 
ShcllGetExtraData Returns the pointer to the extra data that 

were passed with the top-most URL. 
URL GENERATION & DECOMPOSITION 



ShcllParseURLArgs Begin parsing the arguments that were 

encoded in a URL. Arguments arc of the 
form "name= value", with multiple 
arguments separated by characters. 
Arguments usually follow the first in a 
URL. 

Fetches the next argument from the argument 
list, using the token returned by 
ShellParseURLArgs. 
Finish parsing arguments from a URL. 
Shorthand function that will search a 
URL argument string for specific arguments 
and return their values. Some arguments may 
be marked as mandatory, causing no values 
to be returned if not all the mandatory 
arguments are present. 
Begin constructing a URL argument list 
An initial set of name/value pairs may be 
given in this call. 

Adds another name/value pair to the 
argument list that's being built. 
Returns the now-complete argument string 
with all name/value pairs suitably formatted 
and encoded. 

Specifies the URL for which these are the 
arguments. ShellFinishURLArgs will return 
the URL with the arguments attached. 
Encodes a string for inclusion in a URL 
argument list. This is used by 
ShellAppendURLArg and 
ShellBeginURLArgs, but is also made 
available for general use. 
CONTENT STREAM MANAGEMENT 

ShcllCreateContentStream Allocates a ContcntStream structure for a 

stream of the passed type. 
ShellCloseContcntStream Closes a content stream and frees the 

ContentStream structure. 
SOFTKEY MANAGEMENT 

ShellDefineKeyGo Requests that a softkey be given a particular 

label, and when the key is pressed, the 
current content handler's ContenlActivate 
function be given the passed string. 



ShellGetNextURLArg 



ShellDoneWithURLArgs 
ShellFindURLArgs 



ShellBeginURLArgs 

ShellAppendURLArg 
ShellFinishURLArgs 

ShellPrependURLToArgs 

ShellEncodeURLArg 
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-continued 



-continued 



FUNCTION 



PURPOSE 



FUNCTION 



PURPOSE 



Shell DeftneKey Back Requests that a softkey be given a particular 

label, and when the key is pressed, 
ShellGoBack be called with the passed 
argument. 

Shell DefineKeyMenu Requests that a softkey be given a particular 

label, and when the key is pressed, it bring 
up a menu with the passed entries. When one 
of the entries is selected, the current 
content handler's ContentActivate function is 
called with the string specified for the 
selected entry. 

ShellDefineKey No thing Requests that a softkey have any previous 
binding removed. 
MISCELLANEOUS SCREEN ELEMENTS 



ShellDisp lay Status If the status message area is visible, the shell 

will display the passed message in that area. 
ShellDisplayTitle If the title area is visible, the shell will 

display the passed title in that area. 
ShellSetScro liable Lets the user know whether the content can 

be scrolled in either direction (up or down). 
ShetlSetNewMail Show or remove the new-mail icon from the 

screen. 

Shell EnlargeContent Requests that the content area be enlarged to 

take over the indicated pieces of the screen. 
The takeover lasts until the next URL is 
displayed and is not automatically 
reestablished when the URL making the 
request is redisplayed. 
TEXT ENTRY MODES 



ShellSetTextEntryMode Changes the global text-entry mode and 
updates the mode indicator on the display. 
The shell itself does not act differently 
based on the mode, but it is the custodian 
of the current mode setting that other parts 
of the present invention consult. 
Sets the shift stale that is used by other 
parts of the invention. The shift state may 
also modify the mode indicator the shell 
displays. 

Fetches the current text entry mode. 
Fetches the current shift state. 
Specifies the sequence of modes through 
which the shell should cycle when 
implementing the default processing for 
the "mode" key. Anywhere from one to 
all three modes may be specified. 
ShellEnforceModcSequencc Ensure that the global mode is set to cither 
any of the modes in the current sequence, or 
to the first mode in the current sequence, 
depending on the passed parameter. 
IDLE-TIME PROCESSING 



ShellSetTextShiftState 



ShellGetTextEntryMode 

ShellGetTextShiftState 

ShellSetModeSequence 



ShellAddldleHook 



SbellRemoveldleHook 



ShellDisableldle 



ShellEnableldle 



Requests that a function be called after a 
specified number of seconds have passed 
without any user input. 
Removes a function that was previously 
registered with ShellAddldleHook 
Disables all idle-time processing. This 
may be called multiple times, but each call 
must be matched by a corresponding call to 
ShellEnableldle. 

Re-enables idle-time processing if there are 
no more outstanding calls to 
ShellDisableldle. 
MISCELLANEOUS FUNCTIONS 



ShellPowerOff 



Pops all URL's off the URL stack and asks 
the portability layer to power off the device. 



ShellStandardDialog Brings up a full-screen dialog in a standard 

format. The caller can specify the message, 
the style of dialog desired, what to do with 
the softkeys, and a time without user input 
after which to take a default action. 



We claim: 

1. A computer- implemented method of operating a wire- 
less communications device having a plurality of keys, 
comprising: 

receiving a first markup language page containing a tag, 
the tag defining a new association between one of the 
keys and an action; 

receiving a user selection of the key; and 

effecting, with the wireless communication device, the 
action associated with the user selected key. 

2. The method of claim 1, wherein the action is a URL 
having a data component, further comprising: 

responsive to the data component of the URL specifying 
a second page to be fetched, fetching the second page, 
and displaying the second page. 

3. The method of claim 1, wherein the action is a URL 
having a data component, further comprising: 

responsive to the data component of the URL specifying 
a telephony command of the wireless communication 
device, executing the telephony command. 

4. The method of claim 1, wherein the tag specifies a 
URL, and further comprising: 

responsive to user input selection of the key, fetching 
content associated with the URL and displaying the 
content. 

5. The method of claim 1, wherein the tag specifies a label 
associated with the specified key, and further comprising: 

responsive to decoding the page, displaying the label. 

6. The method of claim 1, wherein the step of receiving 
the first markup language page additionally comprises: 

decoding the first markup language page including the tag 
specifying the key and the action; and 

storing the association between the key and the action. 

7. A browser program product for controlling the opera- 
tion of a wireless communication device by execution of the 
browser by a processor of the wireless communication 
device, the wireless communication device having a plural- 
ity of keys, the browser executing the operations of: 

receiving a first markup language page containing a tag, 
the tag defining a new association between one of the 
keys and an action; 

receiving a user selection of the key; and 

effecting, with the wireless communication device, the 
action associated with the user selected key. 

8. The browser program product of claim 7, wherein the 
step of receiving the first markup language page additionally 
comprises: 
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decoding the first markup language page including the tag 
specifying the key and the action; and 

storing the association between the key and the action. 

9. The browser of claim 7, wherein the tag specifies a 
URL, and responsive user input selection of the key, the 
browser fetches content associated with the URL and dis- 
plays the content. 

10. The browser of claim 7, wherein the tag specifies a 
label associated with the specified key, and the browser 
responsive to decoding the page, displays the label. 

11. The browser of claim 7, wherein the action is a URL 
having a data component, further comprising: 

responsive to the data component of the URL specifying 
a second page to be fetched, fetching the second page, 
and displaying the second page. 

12. The browser product of claim 7, wherein the action is 
a URL having a data component, further comprising: 

responsive to the data component of the URL specifying 
a telephony command of the wireless communication 
device, executing the telephony command. 

13. A method of configuring a wireless communication 
device having a screen display and a plurality of user 
selectable keys, the method comprising: 

receiving a data file including content and markup lan- 
guage tags defining an arrangement of the content on 
the screen display, a portion of the content associated 
with a URL; 

responsive to at least one of the markup language tags, 
displaying the portion of the content associated with the 
URL on the screen display in a visually distinguished 
manner; 

responsive to at least one of the markup language tags, 
assigning the URL associated with the visually distin- 
guished content to one of the user selectable keys; 

receiving a user selection of the assigned user selectable 
key; and 

accessing a data file or function associated with the URL 
assigned to the user selected key. 



14. A computer implemented method of processing a page 
of data encoded in a markup language, the page including a 
reference to an embedded object, the method comprising: 

receiving a user selection of a displayed user interface 
element in the page, the element associated with a 
command encoded within the page; and 

invoking the embedded object, and providing the com- 
mand to the embedded object for processing, the 
embedded object processing the command using an 
internally defined function. 

15. Acomputer implemented method of processing a page 
of data encoded in a markup language, the page including a 
specification for an embedded object, the method compris- 
ing: 

creating the specified embedded object; 

receiving a user selection of a displayed user interface 
element in the page, the element associated with a 
command encoded within the page; and 

invoking the embedded object, and providing the com- 
mand to the embedded object for processing, the 
embedded object processing the command using an 
internally defined function. 

16. The computer implemented method of claim 15, 
further comprising storing a reference to the created embed- 
ded object. 

17. The computer implemented of claim 16, wherein 
invoking the embedded object further comprises locating the 
stored reference to the created embedded object. 

18. A computer implemented method of automatically 
displaying help data to a user, comprising: 

displaying a window having a title in a title bar area; 

incrementing a counter of an amount of time elapsed since 
a last user input; and 

responsive to the counter equaling or exceeding a thresh- 
old amount of time, replacing the title with help data in 
the title bar area. 

* * * * * 
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